http://mivo.truxoft.com
MIVO!
miva beyond limits

1. Features
2. Description
3. Installation
4. Error Messages and Warnings
5. Common Mistakes
6. Limitations and known bugs
7. Support
8. BUY IT
9. FAQ
10. License agreement
11. Change Log
12. Useful links
13. User Comments

top

• Analyses common and rare configuration problems in Miva engine installation
• Unlike the official Miva Diagnostic Program (diag.mv), it provides much deeper system analyses.
• Offers advices for fixing reported problems.
• Analyses and reports security problems in Miva Empresa setup
• Verifies runaway processes in Unix Shell (if available)
• Shows available optional Miva engine features
• Measures Miva enigne performance
• Drop-in solution. No installation necessary. No configuration.

top

At many hosts, Miva Empresa is too often installed in an insecure way or misconfigured in such a way that it restricts some functions (i.e. modules upload), makes the maintenance difficult, and/or disables the use of some 3rd party modules.

I found the official Miva diagnostic tool (diag.mv) as very insufficient and unreliable in many cases, and therefore have written a tool that provides much deeper analysis of the server, and besides giving some tips for solving many issues, it also reports diverse security problems.

top

Put the txdiag.mvc wherever you want in the Miva Script directory (public web area). Call it through the browser in the following way:

or (compiled version):

or (on a local PC with Mia VM on default port 80):

or (compiled version on a local PC with Mia VM on port 8000):

From the TxDIAG interface, you can restrict access to the program - only your PC (using unique ID in a cookie) will be permitted to launch it. If you need to access TxDIAG from another PC, you'll have to delete file txdiag.conf from the Miva Data directory.

By default TxDIAG sends statistical data to the truXoft server. This data are used especially for comparing your server performance with other servers. If you do not wish that TxDIAG sends the data to truXoft, you can deny it in the txdiag.conf - replace the string 'log' with 'no'. TxDIAG never sends any data from local installation under Miva Mia, you can check the conf file after running TxDIAG locally. If you want to use it on the server, to avoid running it with reporting enabled, remove the 32bytes callerid.

top

error list

TxDIAG was unable to delete the temporary test directory created in previous TxDIAG session. There may be numerous reasons for it. Delete it manually through Telnet/SSH or FTP to get eventually another error message telling you more precisely what is wrong.

• The directory was created before running TxDIAG by another program or manually
• TxDIAG interrupted in previous session with different Miva Empresa settings
• Wrong ownership of Miva Data root directory
• Wrong ownership of Miva Empresa
• Miva Empresa not setuid

error list

TxDIAG was unable to create a temporary test subdirectory in Miva Data directory.

• Improperly defined or undefined Miva Data root directory
• Wrong ownership of Miva Data root directory
• Wrong ownership of Miva Empresa
• Miva Empresa not setuid

error list

TxDIAG was unable to create a temporary test file and write to it.

• Improperly defined or undefined Miva Data root directory
• Wrong ownership of Miva Data root directory
• Miva Data directory not writeable by the Miva Empresa uid
• Wrong ownership of Miva Empresa
• Miva Empresa not setuid
• Disk quota exceeded

error list

TxDIAG was unable to read from the previously created temporary test file.

• Wrong Miva Empresa binary
• Corrupted disk

error list

TxDIAG was unable to access the previously created temporary test file.

• Wrong ownership of Miva Data root directory
• Wrong ownership of Miva Empresa
• Miva Empresa not setuid
• Corrupted disk

error list

TxDIAG was unable to delete the temporary test file created in the Miva Data directory in a previous pass.

• Wrong ownership of Miva Data root directory
• Wrong ownership of Miva Empresa
• Miva Empresa not setuid
• Miva Data root directory not readable by Miva Empresa owner uid

error list

TxDIAG was unable to delete the temporary test subdirectory created in the Miva Data directory in a previous pass.

• Wrong ownership of Miva Data root directory
• Wrong ownership of Miva Empresa
• Miva Empresa not setuid
• Miva Data root directory not writable by Miva Empresa owner uid

error list

TxDIAG was unable to delete the temporary test file copied to the Miva Script directory in a previous pass.

• Wrong ownership of Miva Data root directory
• Wrong ownership of Miva Empresa
• Miva Empresa not setuid

error list

TxDIAG was unable to delete the temporary test file created in the Miva Script directory in a previous TxDIAG session.

• The file was created before running TxDIAG by another program or manually
• TxDIAG interrupted in previous session with different Miva Empresa settings
• Wrong ownership of Miva Script root directory
• Wrong ownership of Miva Empresa
• Miva Empresa not setuid
• Miva Script root directory not writable by Miva Empresa owner uid

error list

TxDIAG was unable to delete the temporary test subdirectory created in the Miva Script directory in a previous TxDIAG session.

• The directory was created before running TxDIAG by another program or manually
• TxDIAG interrupted in previous session with different Miva Empresa settings
• Wrong ownership of Miva Script root directory
• Wrong ownership of Miva Empresa
• Miva Empresa not setuid
• Miva Script root directory not writable by Miva Empresa owner uid

error list

TxDIAG was unable to create a temporary test subdirectory in the Miva Script directory.

• Improperly defined or undefined Miva Data root directory
• Wrong ownership of Miva Script root directory
• Wrong ownership of Miva Empresa
• Miva Empresa not setuid

error list

TxDIAG was unable to create a temporary test file and write to it.

• Improperly defined or undefined Miva Script root directory
• Wrong ownership of Miva Script root directory
• Miva Script directory not writeable by the Miva Empresa uid
• Wrong ownership of Miva Empresa
• Miva Empresa not setuid
• Disk quota exceeded

error list

TxDIAG was unable to copy a temporary test file from the Miva Data to the Miva Script directory.

• Unequal ownerships of Miva Data and Miva Script directories
• Improperly defined or undefined Miva Script root directory
• Wrong ownership of Miva Script root directory
• Miva Script directory not writeable by the Miva Empresa uid
• Wrong ownership of Miva Empresa
• Miva Empresa not setuid
• Disk quota exceeded

error list

TxDIAG was unable to move a temporary test file from the Miva Data to the Miva Script directory.

• Unequal ownerships of Miva Data and Miva Script directories
• Improperly defined or undefined Miva Script root directory
• Wrong ownership of Miva Script root directory
• Miva Script directory not writeable by the Miva Empresa uid
• Wrong ownership of Miva Empresa
• Miva Empresa not setuid
• Disk quota exceeded

error list

TxDIAG was unable to execute (MvDO) a temporary test file.

• Improperly defined or undefined Miva Script root directory
• Wrong ownership of Miva Script root directory
• Miva Script directory not readable by the Miva Empresa uid
• Wrong ownership of Miva Empresa
• Miva Empresa not setuid

error list

The execution of the temporary test file gave a wrong result.

• Wrong or corrupted Miva Empresa binary

error list

TxDIAG was unable to delete the temporary test file.

• This error appears on some Windows systems (especially with Miva Mia), where the engine locks the test file after executing it with MvDO. This is not a critical error.
• Wrong ownership of Miva Script root directory
• Wrong ownership of Miva Empresa
• Miva Empresa not setuid
• Miva Script root directory not writable by Miva Empresa owner uid

error list

TxDIAG was unable to delete the temporary test subdirectory.

• Wrong ownership of Miva Script root directory
• Wrong ownership of Miva Empresa
• Miva Empresa not setuid
• Miva Script root directory not writable by Miva Empresa owner uid

error list

• Wrong ownership of Miva Script root directory
• Wrong ownership of Miva Empresa
• Miva Empresa not setuid
• Miva Script root directory not writable by Miva Empresa owner uid
• Miva Empresa version prior v3.5x

error list

• Wrong ownership of Miva Script root directory
• Wrong ownership of Miva Empresa
• Miva Empresa not setuid
• Miva Script root directory not writable by Miva Empresa owner uid
• Miva Empresa version prior v3.5x

error list

File export did not report any problems, but the exported file was not found.

• Currently unknow. Improbable error.

error list

TxDIAG was unable to make both GET and POST HTTP requests through the MvCALL command. Connections to remote servers and to local non-miva applications are not available.

• Environment variables misconfigured
• Blocking of outgoing connections for security reasons (i.e. firewalls)
• Limitation of proxy server
• No connection to the Internet
• DNS misconfiguration
• Router problems
• wrong netmask

The last case - wrong netmask was reported by Curtis Wong on a FreeBSD server:
"Systematic testing isolated the problem to a network addressing issue related to the freebsd network code implementing (virtual) ip aliasing on a common subnet. A nonconflicting netmask is needed. In our case a 0xffffffff netmask is required. It is not optional."

error list

TxDIAG was unable to make a GET HTTP requests through the MvCALL command. POST method works.

• Blocking of outgoing GET HTTP requests for security reasons (i.e. firewalls)
• Limitation of proxy server

error list

TxDIAG was unable to make a POST HTTP requests through the MvCALL command. GET method works.

• Blocking of outgoing POST HTTP requests for security reasons (i.e. firewalls)
• Limitation of proxy server

error list

Relatively rare problem, when MvCALL return no values in http header variables and instead of it attaches the entire header to the MvCALL body in s.callvalue. It can cause problems for example in MIva Merchant modules using MvCALL to connect to a remote server for shipping calculation, fo license verfication, etc.

• currently unknown

error list

• Wrong ownership of Miva Script root directory
• Wrong ownership of Miva Empresa
• Miva Empresa not setuid
• Miva Script root directory not writable by Miva Empresa owner uid

error list

• Wrong ownership of Miva Script root directory
• Wrong ownership of Miva Empresa
• Miva Empresa not setuid
• Miva Script root directory not writable by Miva Empresa owner uid

error list

• Wrong ownership of Miva Script root directory
• Wrong ownership of Miva Empresa
• Miva Empresa not setuid
• Miva Script root directory not writable by Miva Empresa owner uid

error list

• Wrong ownership of Miva Script root directory
• Wrong ownership of Miva Empresa
• Miva Empresa not setuid
• Miva Script root directory not writable by Miva Empresa owner uid

error list

• Wrong Miva Empresa binary
• ?

error list

• Wrong Miva Empresa binary
• ?

error list

Miva Empresa should be owned by the same user ID (uid) as the owner of the server account and set to run under this uid with the permission 47xx (i.e. 4755, 4700 or similar). This does not seem to be the case at this installation - runs under the uid 'nobody', what is definitely wrong.

error list

The tested Miva engine is of a version with well known very serious security flaws. An intruder could very easily break into your server. Read more details in the Security Update Log. You should contact your host or system administrator and ask them to update to the newest version immediately! Security updates are available for free from Miva Co.

error list

You are using an older, outdated Miva engine version. It is missing important features and may be considerable slower than the recently available engine. You should contact your host or system administrator and ask them to update to the newest version! Updates are available for free from Miva Co.

error list

Your Miva Empresa is configured so that it does not use its default "sandbox" security concept, where both the data and the script files are in independent encapsulated space. Your setup allows use of absolute paths, it means Miva application can access any files on your server. It may be extremely dangerous especially in conclusion with other security flaws or use of 3rd party Miva Script applications. It can also cause run-time problems with certain Miva applications. You should contact your host or system administrator and ask them to disable absolute paths in the miva.conf file. It is controlled by the parameter securityoptions. Details may be found in the Miva Empresa Unix Configuration Manual.

error list

Miva Data directory must be not only in a space completely isolated from the public web area, but for security reasons the permissions of the directory and all its files and subdirectories must be set to be writable by the owner only (Unix permissions 700). In a Telnet or SSH session, you can change the permissions with a single command:

(where mivadata is the path of your Miva Data directory)

error list

Miva Data directory must be not only in a space completely isolated from the public web area, but for security reasons the permissions of the directory and all its files and subdirectories must be set to be readable by the owner only (Unix permissions 700). In a Telnet or SSH session, you can change the permissions with a single command:

(where mivadata is the path of your Miva Data directory)

error list

Letting the data directory in public web folder is one of the worst mistakes an administrator can make when installing Empresa. Only the most incompetent hosts ignoring any security measures would do it. Although some hosts protect the data files from direct access by setting in Apache configuration files or through file permissions or ownerships, it is definitely insufficient protection. Usually it may be bypassed within few seconds and an intruder may be able to download your files containing valuable data (like for example credit card numbers) without any hassle.

error list

Oh! This kind of configuration is definitely not acceptable. The ever worst case. Run away from the host as fast as you can. Data and Script directories must be completely isolated, independent, and the data directory must not be in any space addressable from the web.

error list

Letting script directory writable by anybody else than the owner is carefree and should be avoided. This mistake is usually made by administrators who are unable to install Miva Empresa correctly setuid.

error list

With current Miva Empresa versions it should not be possible that a directory created by a Miva script has permissions set to be writable by 'others' and it is a very serious security flaw.

error list

With current Miva Empresa versions it should not be possible that a directory created by a Miva script has permissions set to be readable by 'others' and it is a very serious security flaw.

error list

error list

Symbolic links are enabled only in the Miva Script directory. See also details above.

error list

Symbolic links are enabled only in the Miva Data directory. See also details above.

error list

Symbolic links seem to be enabled, but for some reasons are not functional in both Miva Data and Miva Script directory. A possible reason may be improper ownerships in Miva Data directory or insufficient securityoptions setting. See also details above.

error list

Symbolic links seem to be enabled, but for some reasons are not functional in Miva Data directory. A possible reason may be improper ownerships in Miva Data directory or insufficient securityoptions setting. See also details above.

error list

Symbolic links seem to be enabled, but for some reasons are not functional in Miva Script directory. A possible reason may be improper ownerships in Miva Data directory or insufficient securityoptions setting. See also details above.

error list

Symbolic links are enabled and correctly working, but cannot be use in web documents to link to files in the Miva Data directory. This restriction is usually caused either by restrictions in Apache's configuration files (Options -FollowSymLinks) or the data directory is in a tree not accessible by Apache due to a cgi-wrapper (i.e. suexec) used. Changing it is usually not necessary, and often not even easily possible.

error list

Not any configuration problem. The warning only tells that your system setup does not seem to allow the creation or the modification of Apache configuration files through a Miva script.

error list

It looks like Apache .htaccess files may be viewed by a visitor. It is not a serious security problem, but it may disclose important sensitive information about your server. It is recommended to protect configuration files from access by the following setting in httpd.conf or in the main .htaccess file:

<Files ~ "^\.ht">
 Order allow,deny
 Deny from all
</Files>

error list

At directories that do not contain any index file, your server automatically generates directory indexes and displays them to the visitor. It may disclose important sensitive information about your server structure. It is recommended to protect your account with the following setting in httpd.conf or in the main .htaccess file:

error list

Not any configuration problem. The warning only tells that your system setup does not seem to allow the use of Unix Shell script by a Miva script.

error list

Your Miva Empresa is improperly configured to use long cgi-bin formed URLs, without any protection recommended in the Miva Empresa Installation manual. If for some reason the long cgi-bin URLs have to be enabled, the validextensions parameter in miva.conf must be set. Usually, validextensions=.mv setting is sufficient. Better yet, is disabling long URLs with setting redirectonly=yes. See more details about this vulnerability in art0001.

error list

Newer versions of Miva Empresa (v3.94 and v4.xx) support SSL in MvCALL commands. This feature is available only is OpenSSL library is installed on your system and properly configured. If TxDIAG reports that OpenSSL support is not available, it means that you are either using older Miva engine, or the OpenSSL library was not found.

error list

On Unix systems where Shell is accessible to Miva scripts, TxDIAG verifies Unix environment for runaway processes and reports them if some found. Runaway processes may very negatively influence the performance of the server. Read more about them in art0033.htm

top

This is the very most common mistake made at Miva Empresa installation. It may be often found at many hosts and the biggest and most known ones are often the worst examples.

Miva Empresa can be installed in two modes: Server Safe and Standard. Server Safe mode is not used as often as the Standard mode, because it is little bit more complicated to set up. Most problems use to happen in the Standard Installation.

• Server Safe Installation with a common miva binary, miva.conf configuration file in the root (/etc/miva.conf) and an authorization file assigning data directories to individual accounts.
  Miva Empresa binary must be owned by the 'root' uid (user id) and permissions must be set to 4755.
• Standard Installation with the Miva Empresa binary in user's private cgi-bin folder. Miva configuration file may be either in root (/etc/miva.conf) or in the same directory as Empresa. No authorization file is required. Miva Empresa binary must be owned by the uid of the account owner and must be setuid (permissions 4755, or preferably 4700). The only exception is an Apache server that is configured to use suexec (cgi wrapper) - in such case the miva binary must be still owned by the account uid, but must NOT be setuid (i.e. permissions 111 or 755). See also below.

So the conclusion: on a Unix server, there are currently only three correct ways to install Miva Empresa:

1. Server Safe Install - owned by root, setuid 4755 (srwxr-xr-x)
2. Standard Install - owned by account uid, setuid 4755 (srwxr-xr-x)
3. Wrapped Install - owned by account uid, permissions 755 (rwxr-xr-x)
   (suexec wrapper must be enabled!)

Using any other uid than the one of the account owner (resp. 'root' uid in case of Server Safe installation) is definitely wrong. Esecially wrong is using Apache's uid, generic uid like 'nobody', or using 'root' uid in Standard or Wrapped installation mode!

Normally, the setuid permissions (4755) tell the system to use the owner's uid (user id) whenever the file is run, including when it is run by others (like for example when launched from the web by a visitor - that happens at every Miva driven page). If the binary is setuid, Miva Empresa can access data files owned by the account owner. If it is not setuid, it runs with the permission of the visitor (usually 'nobody') and cannot access any data files unless they are owned by the same uid or set world readable and writable - both of such configurations would be very wrong, but unfortunately are quite common at many hosts who are not security aware or are not interested enough in running their business professionally.

common mistakes

As written above, at Apache servers using suexec cgi wrapper for higher security, Miva Empresa cannot be setuid and its permissions have to be set to 755. Setuid setting (4755) would cause 500 Internal Server Error. The same effect would have using another than uid than the one of the account owner. For these reasons, cgi wrapped accounts are usually correctly configured - the wrapper practically does not allow wrong setting (at least as long as the wrapper itself is correctly configured, of course).

common mistakes

The correct permissions of Miva Empresa binary in different installation modes are explained above. Practically there are only three posibilities:

1. Server Safe Install - owned by root, setuid 4755 (srwxr-xr-x)
2. Standard Install - owned by account uid, setuid 4755 (srwxr-xr-x)
3. Wrapped Install - owned by account uid, permissions 755 (rwxr-xr-x)
   (suexec wrapper must be enabled!)

The group and world permissions (last two digits) may be usually set to 1 or even 0, without any impact on the functionality.

common mistakes

When Miva Empresa is installed in the Secure Safe mode (common miva binary in the root), it requires so-called authorization file with definitions of users' privileges and data directories. Details about settings in authorization file may be found in the Unix Authorization File Reference Manual

common mistakes

As explained above, miva binary must be owned by root when (but ONLY WHEN) Server Safe installation is used with a common binary and the authorization file in the root. Using the 'root' uid at a binary in the Standard Installation mode (miva in private cgi-bin directory) would be a deadly and very dangerous mistake!

common mistakes

Miva Corporation offers many Empresa builds for different OS and hardware platforms. For the very common Linux servers, there are three versions available (at least at Miva Empresa 3.xx). You have to use the one that corresponds to the Libc library available on your server. Practically all current Linux servers have the Glibc v2 library installed, and some of them even one of the Libc v5.3 or v5.4. The Libc builds are faster than the Glibc version, but if your server does not have the correct library, it may lead to weird problems.

Another common problem is at some Cobalt servers - there is a Cobalt version available at ftp.miva.com too, but some Cobalt servers are in fact PC based Linux machines and the Linux Empresa has to be used.

common mistakes

Miva Data directory must be owned by the same user id (uid) as the account owner. It means that practically all files that can be found in the account, should be owned by the same uid - both data and script files.

This is a very common mistake made by system administrators who did not read or did not understand the Miva Empresa Installation manual and did not setuid the Miva Empresa binary as described there and also above. When Miva Empresa runs with a wrong user id, inexperienced system administrators try to "fix" it by changing the ownership or permissions of the data and script directories. They usually mistakenly change the ownerships to the 'nobody' uid or made the entire directory structure world writable and readable - very dangerous!

It makes the problem even much worse than it already was and exposes the data to potential disclosure due to this serious security flaw.

common mistakes

Same as above: inexperienced or incompetent system administrators, to bypass problems caused by wrong non-setuid Miva Empresa installation, often change the permissions of the Miva Data directory tree to be world writable and readable! Very serious security flaw!

common mistakes

Practically the same as written in Wrong ownership of Miva Data directory applies also in the case of the Miva Script directory.

common mistakes

Practically the same as written in Wrong permissions of Miva Data directory and Wrong ownership of Miva Data directory applies also in the case of the Miva Script directory.

common mistakes

One of the very worst mistakes made by hosts and system administrators at Miva Empresa installation, is ignoring instructions and all security notes written in the Miva Empresa Installation manual and creating the Miva Data directory within a space accessible or addressable from the Web. In the better case they naively think that protecting the data with a .htaccess file or with removing the world permission is a sufficient protection, but they do not know how very far they are from the truth.

If, by accident, you are hosted by such a company who either mixes both Miva Data and Miva Script files in the same directory tree, or has the Miva Data in a publicly accessible space, do not wait any minute more and run away as quick as you can. Find a new host who understands at least the very basic principles of security. Better yet, find a host who is responsible and specialized in Miva hosting. You will find tips in the Miva user groups.

common mistakes

Explained above. If the setup was made by your host, do not walk, RUN AWAY!

common mistakes

Using absolute paths violates the principles of the Miva Empresa's security concept with encapsulated and separate Miva Data and Miva Script containers (so called "sandbox" principle). Although Miva Empresa allows configuration using absolute paths, instead of the default paths with roots in the two Data and Script directories, it is intended for advanced applications made by very experienced and well security aware developers for solving complicated special tasks. Absolute paths are in no case necessary in any common Miva Empresa installation, and they are never needed for Miva Merchant.

With using absolute paths, some administrators mask their incompetence to set up Miva Empresa properly. If your host uses absolute paths without any well grounded reason, you should better turn back very quickly and look for a professional provider specialized in Miva hosting.

common mistakes

Miva scripts may be called in two ways:

1. Redirects (http://domain/script.mv) - the redirection for the .mv extension must be set in one of Apache's configuration files. It may be defined also locally in .htaccess:
   AddType application/x-httpd-Miva mv
Action application/x-httpd-Miva /cgi-bin/miva
   This is today the standard and recommended way.
2. Direct calls with miva binary in the URL - cgi-bin formed URLs. This way is insecure (see details at art0001) and if possible should be completely avoided. It can be disabled in miva.conf with the setting redirectsonly=yes.

It is a very common mistake of almost all hosts I know, that the long cgi-bin formed URL has to be used at accounts with an SSL certificate of the host instead of an own one (i.e. https://domain.host.com). It is a wrong assumption, Miva Empresa may be configured to use short redirect URL in secure mode too. More details may be found in art0014

If long URL's are allowed, they must be protected with the validextensions=.mv setting in miva.conf, to avoid the most serious consequecies.

common mistakes

See detailed explanation above. In this case not only that the long URL's are not disabled, but they are not even protected by the validextensions configuration directive in miva.conf! I would recommend leaving a host with such configuration immediately - it clearly shows their ignorance of very basic security principles of web hosting.

top

not reported any

top

truXoft offers a  limited free suport  within 30 days after the date of the purchase for modules bought directly at  truXoft Co. or at affiliated resellers as listed below. The support is limited to fixing evident unknown bugs. It does not include any help with configuration or installation of your Miva Empresa or Miva Mia. Before submitting any support query, please be absolutely sure to have entirely read the chapters Limitations and known bugs and FAQ.

Some questions may be already answered in the FAQ or may be solved with the help of other more experienced users on the Miva Script User List. I am monitoring all Miva user lists and, if possible, will help with related problems posted to the user groups.

top

faq

top

BY INSTALLING THIS SOFTWARE YOU AGREE TO THE FOLLOWING LICENSE:

Definitions:

• "YOU" and "LICENSEE" refers to the person, entity or organization which is using the software and source code known as "truXoft TxDIAG Miva Diagnostic Program", and any successor or assignee of same.
• "truXoft TxDIAG" (hereinafter "TxDIAG") is the application accompanies this License, and which allows parsing of Miva^® Script^TM, and which requires the use of Miva^® Virtual Machine^TM.
• "Miva^® Virtual Machine^TM" (hereinafter "MVM") is a Miva Corporation's server side application for parsing compiled Miva^® Script^TM documents.
• "Server" is any device connected to any private or public network, such as LAN, WAN or Internet and used for serving documents processed by the Miva Virtual Machine (MVM).

1. This license is for the downloading and use of TxDIAG. By downloading, acquiring and using TxDIAG, YOU expressly agree to abide by this License.
2. This license is between LICENSEE and truXoft. Licensee acknowledges that truXoft is and has granted this license in reliance upon representations made by Licensee and Licensee warranties the truthfulness and accuracy of such representations. Any breach of this warranty of truthfulness and accuracy shall constitute a breach of this License. truXoft has the sole and unqualified right to refuse to license any person or entity for any reason, except for reasons which are specifically prohibited by state and national laws and statutes.
3. LICENSEE is granted a non-exclusive license to use TxDIAG in conjunction with one server for each TxDIAG licence purchased. License to use TxDIAG with more than one server, must be separately purchased from truXoft and are specifically not granted in this License. LICENSEE is additionally granted using maximally one copy of TxDIAG on a personal PC for evaluation, develpment and debugging.
4. TxDIAG contains valuable proprietary rights of truXoft. There is no transfer to LICENSEE of any title to or ownership of TxDIAG or any copyright, trade name, trade secret, source code, or other proprietary rights relating to TxDIAG, regardless of the form that TxDIAG exists in. Licensee may not violate these rights, and Licensee must take all appropriate steps to protect truXoft's rights. truXoft may at any time replace, modify, alter, improve, enhance, or change TxDIAG without prior notice.
5. Any license, right, or permission to use TxDIAG is automatically revoked if LICENSEE breaches any term or condition of this License. Licensee agrees that in the event of a breach of this License, and upon the demand thereof by truXoft, Licensee will immediately return any physical copies of TxDIAG to truXoft, will cease any further use of TxDIAG, will remove the original and any modified or altered copies of TxDIAG from his/her/its computers and drives, will cease his/her/its use of TxDIAG, and will cease any claimed breach of this License. Licensee agrees that monetary damages alone is not an adequate and just relief resulting from any breach of this License, that a court TxDIAG prohibiting any further breach of this License is necessary to prevent further damages, and that Licensee will not oppose any reasonable request for a temporary restraining TxDIAG, preliminary injunction, or other relief sought by truXoft in the event of a breach of this License. truXoft shall not be required to notify Licensee of any breach, nor make any demand or claim against Licensee resulting from any such breach, or for a demand to stop any use or distribution in violation of the terms of this License, and Licensee agrees that any breach of this License and damages resulting therefrom shall relate back to the first and earliest breach thereof. Failure of truXoft to enforce its rights pursuant to this License shall not constitute a waiver of such rights, and shall not prejudice truXoft in any later enforcement of its rights or rights to seek damages therefrom.
6. truXoft WILL NOT BE LIABLE FOR (A) ANY BUG, ERROR, OMMISSION, DEFECT, DEFICIENCY, OR NONCONFORMITY IN SEK; (B) IMPLIED MERCHANTIBILITY OF FITNESS FOR A PARTICULAR PURPOSE; (C) IMPLIED WARRANTY RELATING TO COURSE OF DEALING, OR USAGE OF TRADE OR ANY OTHER IMPLIED WARRANTY WHATSOEVER; (D) CLAIM OF INFRINGEMENT; (E) CLAIM IN TORT, WHETHER OR NOT ARISING IN WHOLE OR PART FROM truXoft'S FAULT, NEGLIGENCE, STRICT LIABILITY, OR PRODUCT LIABILITY, OR (F) CLAIM FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES, OR LOSS OF DATA, REVENUE, DEVELOPERS GOODWILL, OR USE. IN NO CASE SHALL truXoft'S LIABILITY EXCEED THE PRICE THAT DEVELOPER PAID FOR TxDIAG.
7. This License Agreement shall be governed by the laws of the State of Nevada, USA. If any provision of this License is found void, invalid, or unenforceable, it will not affect the validity of the balance of this License, which shall remain valid and enforceable according to its terms. In the event any party is required to seek judicial enforcement regarding any terms of this License, or to seek a judicial interpretation regarding any terms of this License, the party deemed by the court to be the prevailing party shall be entitled to, in addition to its costs and damages, reasonable attorney's fees and costs as determined by the court.
8. LICENSEE acknowledges that TxDIAG may be subject to United States export controls, pursuant to the Export Administrations Regulations, 15 C.F.R. Parts 768-799. Licensee shall comply strictly with all requirements of the Export Administration Regulations regarding use of TxDIAG.
9. This License Agreement constitutes the entire and sole agreement between user and truXoft, and is agreed to and entered into on the date YOU download or implement TxDIAG, whichever date is earlier.

top