Martin Fink Speech Summary about HP Nonstop

Recently I read the interview of Martin Fink, the CTO of HP Nonstop Systems. Though it was addressed to HP Employees.  Few things, still applicable to all the NONSTOP users.

I was really impressed by his few words and Rules. Here's those :

Rule 1 : Be selfish

Rule 2 : Make a contribution

Rule 3 : Observe the Customer

Rule 4:  Know your Value Proposition
                 - Data Integrity
                 - Scalablity
                 - Fault Tolerance

Rule 5 : Understand the technology at a very DEEP Level.

                 - Nonstop should Transform from Hardware business to Software Business

Rule 6 :  Structure Follows Strategy

Rule 7 :  Know your Business Model

What's the NEXT for NONSTOP ?

We need to take NONSTOP software strategy into Mainstream. The mainstream software world today tends to revolve around 4 things:

- Linux
- Virtualization
- Open Source
- Cloud

In the HP Labs, Nonstop is running in VM on Linux. Soon, It will hit the market.

And also, bring on X86 and using Infiniband interconnects allows to build HYBRID SYSTEMS that combine Linux, Windows with NONSTOP. That will be POWERFUL COMBINATION.

Opensource is a Business choice. Not a Technology Choice.

Cloud aspires to what Nonstop Already is.

Additional Security Considerations for Pathway

PATHWAY configuration (per PATHMON)

The OWNER attribute specifies the owner of the PATHMON environment. That user can stop the

- PATHMON process,
- Add programs,
- Delete objects,

and make other modifications to the global configuration.

The SECURITY attribute, whose value is relative to the OWNER’s user ID, specifies who else can modify the PATHMON environment after you issue the START PATHWAY command.

• The default is “N” for TS/MP 2.0 and 2.1, and should be changed to “O”.
• The default is “O” for TS/MP 2.3 and later versions.

For all TS/MP versions, prior to issuing the START PATHWAY command the owner is the process access ID (PAID) of the PATHMON process and the SECURITY attribute is O (owner only).

HP recommends that the OWNER of a given PATHMON environment be a user ID associated with management of that specific application, rather than SUPER.SUPER or a member of the SUPER group.

SERVER configuration (per server class)

OWNER specifies the user ID that controls access from a Pathsend process to a specific server class. (The TCPs ignore this server attribute.)

If not specified, OWNER defaults to the user ID who started the PATHMON process. Specify an appropriate user.

SECURITY specifies the users, in relation to the OWNER attribute, who can access a server class from a Pathsend requestor. (TCPs ignore this attribute.) The default is “N”, which should be changed to the most restrictive setting that does not interfere with correct application operation.

For Guardian servers, ensure that server class ASSIGNs and DEFINEs point to the appropriate files, and that the server class volume is explicitly set. Similar considerations apply to CWD and ARGLIST for OSS servers.

For OSS server classes, UMASK specifies the default permissions for the owner, group and others for OSS files created by the server process instance (see General OSS file security for more information on umask).

The default for UMASK is -1; HP recommends that you set it to a more restrictive value (022 or tighter).

Network security

The PATHMON process controlling the server class has to have corresponding user IDs and remote passwords with all of:

• The system where the requesting process is running
• The system where the PATHMON process is running
• The system where the server class is running

This level of security is required because the LINKMON process or the ACS subsystem processes must be able to open the PATHMON process (to make link requests);

the LINKMON process or the ACS subsystem processes must be able to open the server processes (to send user requests);

and the PATHMON process must be able to open the server processes (to send startup messages).

All of these opens are performed with the PATHMON user ID.

Note: If the user starting the PATHMON process is an alias, then the alias must have matching remote passwords on all involved systems. It is not sufficient for the underlying user ID to have matching remote passwords

Note: The user ID of the Pathsend process need not have remote passwords to the PATHMON system or to the server-class system to access the server class.
Moreover, the Pathsend-process user ID need not be known on the PATHMON or serverclass
systems.

Server-class security

LINKMON processes or ACS subsystem processes perform authorization checks on each server-class send operation to make sure that the user ID of the Pathsend process at the time of the send conforms to the server class’s OWNER and SECURITY attributes. You set these

Security Hardening

In Simple Terms, Security Hardening describes the implementation of a series of measures designed to make a system less vulnerable to attacks. A hardened system has a reduced number of attack points making it more difficult to be compromised.

Obvious security recommendations, such as the use of strong passwords, are helpful measures
when trying to prevent breaches or Hacks.

But the implementation of stronger defenses, such as ensuring strong OSS ACCESS permissions, can more challenging to carry out without correct guidance.

And unfortunately,  Information regarding security hardening practices tends to be scattered, difficult to analyze and implement.


Security Hardening should be considered as an ongoing project that will require continuing attention and updating. Companies must constantly look for the latest methods, rules and best practices to ensure that system Data and Services are protected.

Martin Fink's (CTO for HP Nonstop Solutions) View on HP Nonstop

https://www.youtube.com/watch?v=xjUdz8fZ5Wg

Additional security considerations for FUP

General:  Background

You need both read and write access to a file in order to issue an ALTER command against it.  To rename a file, you also need purge access if you are not the super ID.

The FUP INFO command can be used to identify all Guardian files that have LICENSED, PROGID, CLEARONPURGE and/or TRUST set.  It also can display the underlying Guardian security of a file protected by Safeguard at the individual file level.

FUP is used to license SQL/MP object program files.  They cannot be licensed through SQLCI. For SQL/MP files, GIVE applies only to object files.  You must use SQLCI to give away ownership of other SQL/MP files. 

Similarly, PURGE and PURGEDATA apply only to object files and SQLCI must be used for other objects. FUP can display information about OSS files (including their security vectors and whether they are protected by OSS ACLs), SQL/MP object program files and SQL/MX files, but cannot manipulate them in any way.

Non-Safeguard-protected files:  background

You can preserve the source file’s owner ID and Guardian security vector in the copied file if you use SAVEID or SAVEALL with FUP DUP.  The LICENSE attribute is preserved only if the PAID of the current FUP is SUPER.SUPER and the target file resides on the node where FUP is running. 

The same rules apply to PROGID, except that it also is preserved if the PAID of the current FUP is the file owner.  CLEARONPURGE is transferred unconditionally. You need to be either the owner or SUPER.SUPER to GIVE ownership of a file. 

If you are not SUPER.SUPER, you also need purge access to the file. GIVE clears PROGID.  After the GIVE you need to use SECURE to set it again; the usual rules apply. You can use REVOKE to reset CLEARONPURGE and PROGID if you are either the file owner or SUPER.SUPER.  You must be SUPER.SUPER to revoke a file’s LICENSE attribute.

Safeguard-protected files:  background

You need create access to the destination volume and subvolume as well as read access to the input file in order to duplicate a Safeguard protected file.

Caution:  If you use DUP with the PURGE option but do not have create access to the target file, the original file at the target location is purged but the new version is not created.

Caution:  A file’s Safeguard protection is not automatically inherited by the target file.  It will inherit any applicable volumelevel and subvolume-level ACLs on the target volume, and will not be Safeguard-protected if none apply. 

You will need to use SAFECOM to restore or set Safeguard protection for the new file. As with non-Safeguard-protected files, for FUP DUP both SAVEID and SAVEALL transfer the source file’s owner and corresponding security to the target file.

General:  Best practices

You can set the NOPURGEUNTIL attribute to prevent a file from being purged before a specified date and time.

You can use FUP INFO to identify all of the Guardian files owned by a specific user. You can find out what processes and associated users have an Enscribe or SQL/MX file open by using the LISTOPENS command.

Caution:  PURGEDATA does not physically purge the file contents; it simply resets the end of file to zero.  This applies whether or not the file (or system) has CLEARONPURGE set.  PURGE access allows deletion of both a file and its contents, but you can effectively purge the contents of a file without PURGE access through a combination of PURGEDATA and DEALLOCATE.

Caution:  When a file with CLEARONPURGE set is purged, its disk process is going to rewrite the contents with zeros up to the end of the last allocated extent.  The disk process has some built-in pacing for the writes, but this activity still has the potential to negatively affect application and system performance.

SQL/MX object security

SQL/MX object security:  Background 

SQL/MX executes within the OSS environment, but database files reside within the Guardian environment.  For SQL/MX tables, data access uses the ANSI GRANT/REVOKE authorization model. 

SQL/MX is not tightly integrated with Safeguard; however, with SQL/MX version 3.3 and later, Safeguard volume protection can be used to control where SQL/MX objects are created.  SQL/MX uses Guardian security for SQL/MP objects, Installation and fallback:  cautions The initial installation of SQL/MX, done with the InstallSqlmx script, must be run by SUPER.SUPER (not an alias to it).

Do not change the security setting on the anchor file created by SQL/MX.  If the file is modified, SQL/MX ceases to operate.

If you do not use DSM/SCM to do a SQL/MX installation, you must explicitly license the ZCLIPDLL public DLL. 

If this step is not performed, program load errors might occur.

Make sure that the following files are licensed in $SYSTEM.SYSTEM:
• IMPORT
• MXUTP
• MXIMPDDL
• MXAUDSRV
• MXCMP
• MXESP
• MXRTDSRV
• MXTOOL

Make sure that the mxci file in /usr/tandem/sqlmx/bin has both read and execute permissions.

Best Practices

Create a separate SQL/MX security administrator group if running 3.1 or a subsequent version. 

Security administrators manage access to SQL/MX data but they do not have access to the underlying data itself unless explicitly GRANTED access by an object owner or designee or through PUBLIC access. 

Use this group to administer security. 

Consider having only one user create database objects (such as a user designated as the database administrator). 

In that way, no users other than the security administrators and database administrator may grant object access. Periodically audit the set of security administrators. To obtain detailed security administrator information:
OSS> mxci  >> SET SCHEMA nonstop_sqlmx_<system name>.system_security_schema; >> SELECT * FROM privileged_users FOR read uncommitted access;

Use GRANT/REVOKE CREATE CATALOG to restrict the set of users who can create catalogs.

Use ANSI VIEWs to limit access to specific fields of a table to those users entitled to see their contents best practices

How does Linux or Unix based clusters compare with HP Tandem Servers?

Came across, very interesting question on comparing Tandem with Linux, Unix Based Servers.

HP NonStop systems are known for their high availability and reliability, and higher price.
How do Linux or Unix based clusters compare with them, in these respects and others?

On a fault-tolerant machine the fault tolerance is handled directly in hardware and transparent to the application. Programming a cluster requires you to explicitly handle the fault tolerance in the application.

In practice, a clustered application architecture is much more complex to build and error prone than an application built for a fault-tolerant platform such as NonStop. This means that there is a far greater scope for unreliability driven by application bugs, as the London Stock Exchange found out the hard way.

They had an incumbent Tandem-based system, which was quite a common architecture for stock exchange trading applications. Their new CEO had the bright idea that Microsoft was the way forward and had a big-5 consultancy build a .Net system based on a cluster of 120 servers.

The problem with clustered applications is that the failures can be correlated. If an application or configuration bug exists in the system it will typically be replicated on all of the nodes. This means that you can get a single situation or event that can take out the whole cluster. The additional complexity of clustered applications makes them more error-prone to develop and deploy, which raises the odds of this happening. A clustered system built on (for example) Linux and J2EE is vulnerable to the same types of failure modes.

IMHO this is a major advantage of older-style mainframe architectures. Several vendors (IBM, HP, DEC and probably several others I can't think of) made fault tolerant systems. The underlying programming model for this type of system is somewhat simpler than a clustered n-tier application server. This means that there is comparatively little to go wrong and for a given amount of effort you can achieve a more reliable system.

A surprising number of older architectures are still alive and well and living quite comfortably in their market niches.

-   IBM still sell plenty of Z and I series machines;
-   Unisys still makes the A Series and 2200 series;
-   VMS and NonStop are still allive within HP.

The sales of these systems are not all to existing clients - for example a Commercial Underwriting system (GENIUS) runs on the ISeries and is still a market leader in this niche with new rollouts going on as I write this.

The application has survived two attempts to rewrite it (1 in in Java and 1 in .Net) that I am aware of and the 'Old School' platform doesn't really seem to be cramping its style.

Gray & Reuter's Transaction Processing: Concepts and Techniques is somewhat dry and academic, but has a good treatment of fault-tolerant systems architecture. One of the authors was a key player in the design of Tandem's systems