Previous
Index Next
ISCS version 0.1.1
A100 - "Could not retrieve Accessor information" - This error occurs when an Accessor is selected for edit but the Accessor information could not be retrieved from the database. The most common cause is a breakdown in communications with the database server such as a network failure or the database service not running. It is also possible that the Accessor is missing from the database. This is most likely a conflicting change, i.e., some other user has changed the Accessor since the edit database was opened. Refreshing the database will solve this problem. A more ominous problem is if the record is lost because the database is corrupt.
A101 - "The database has already been changed in order to add a new CA. We therefore need to cancel all changes" - This is a bit complicated. When we offer the ability to make changes to multiple items at once, we typically offer the ability to retry, cancel, cancel rest or cancel all if there is a problem with one of the changes. This way, we do not necessarily have to discard all the changes because of a problem with one. However, until the SPM uses nested transactions or savepoints for complex database changes, once a database change has been made within one of those items, we can no longer offer the ability to retry or cancel less than all changes because we only have the option to rollback the entire transaction. We have elected not to use them at this time to maintain database transparency as not all databases support this feature. We also have limited use for it since most of the routines offer an opportunity to retry an individual database failure in case there is a breakdown in network communications or the database server is stopped. This need to retry or cancel a single option presents itself after those individual database retries have already failed. Thus it is likely that all subsequent database access attempts will also fail anyway . In the case of a change to an X.509 Accessor, the addition of a new CA happens very early in the process but is a very rare event. Thus, we wanted to preserve the ability to retry, etc. if a new CA was not added. The error logic thus checks to see if a CA was added. If not, we allow retry, etc. However, if a new CA has been added, all changes are backed out in the event the user elects to cancel when there is a problem with a single entry. This error message alerts them to that fact.
A102 - "Could not retrieve database information for <Access Group Name>" - This error is exactly as it says - the database could not be accessed. It could be a network communications issue, the database may not be running, it may be corrupt or there may be a database rights issue.
A103 - "Could not commit Access Group changes" - This is almost identical to A102 except that the error occurred while trying to commit the entire database transaction, i.e., all the changes at once.
D100 - "Could not access the <table name> database table" - this is a general failure to access the database service. It could be a problem with the service such as the service not running. It could be a database rights issue. It could be a network breakdown between a remote SPM and the database server. It can also occur if a user has multiple RDBMSes on the same server handling different databases, e.g., DBD1 is on Server1 on PostgreSQL while DBD2 is also on Server 1 but on MySQL. Both DBDs will show up in the database list but, if one tries to access DBD2 using PostgreSQL for example, PostgreSQL will not be able to find the database since it has no such database – DBD2 lives only on MySQL.
D101- "Could not start database transaction on database server <DBD IP address>" - this is self-explanatory. We could not start a transaction on the named database server.
D102 - "Could not access the database table" - This error is the same as D100 except we have less information because it was a transaction commit and may have been against more than one table.
D103 - "Could not find any database directories on the selected database server" - The SPM compiles a list of the available databases on a DBD by querying the SPM root directory and selecting all directories which start with the SPM prefix. This error is generated when the list is empty. This could be a misconfigured DBD, insufficient file system rights or a network connectivity problem to a remote DBD.
D104 - The create new database script running on the database server creates an empty database with a SQL command similar to "create database spm_spm". This error means that the creation of the empty database failed. It could be a database rights issue. It could be a mismatch between the database and the selected database type, e.g., the PostgreSQL database type has been chosen when the database is actually MySQL. It could be a disk space issue on the database server.
D105 - Once the new empty database has been created (see errorD104), the database is filled with the data from the skeleton database files. This error means that the portion of the script that fills the database failed. This could be a database rights issue or a disk space issue on the database server.
D106 - This error means that some unexpected error occurred while creating a new database. This is most likely incorrect login credentials or a communication failure either by loss of network connectivity between a remote SPM user and the database server or a failure to establish an ssh session between the two. If it is an ssh error, it is likely that either the user's key is not listed in the database server's .ssh/authorized key file for that user, the user does not have an account on the database server or the user's computer has not authorized the use of ssh to the database server. It is also possible that the script used to create the new database is missing, corrupt or inaccessible (e.g., insufficient file system rights to run the script). It is also possible that the script is not executable.
F100 - "Could not create local files in <directory> on <database server>" - There was a problem writing to the local file system. It may be a permissions or a disk space issue.
F101 - "Could not create remote DBD files in <directory>" - There was a problem writing to the file system on a remote DBD. It may be a network issue, an ssh issue, a permissions issue or a disk space issue. If it is an ssh error, it is likely that either the user's key is not listed in the database server's .ssh/authorized key file for that user, the user does not have an account on the database server or the user's computer has not authorized the use of ssh to the database server.
F102 - "Could not set permissions on local files in <directory>" - After creating local database files, the SPM may attempt to change ownership and permissions. This should rarely occur and may be attributed to permission problems.
F103 - "Could not set permissions on remote DBD files in <directory> on <database server>" - This is very similar to F102 however it could also be provoked by a network or SSH failure.
K100 - "Could not read the certificate in <filename>" - The SPM uses OpenSSL to decode an X.509 digital certificate. This error means that OpenSSL generated an error when attempting to read the certificate. The actual OpenSSL message should be appended to the SPM error message.
K101 - "Could not extract both subject and expiration date for certificate in <filename>" - The SPM uses OpenSSL to read the subject and expiration date. It places each as a separate entry in a QStringList. This error means that the list has less than two entries or, in other words, either the subject or the expiration date could not be extracted from the supplied certificate file.
K102 - "Could not obtain the certificate expiration month" - The SPM uses OpenSSL to read the certificate expiration date. However, the format is not usable by the SPM. The SPM has a routine to convert the date format. It relies upon matching the short month name returned by OpenSSL (e.g., Jan, Feb, Mar) to the names used by the SPM. The SPM attempts to do this in a language and locale independent way. However, if the language or locale settings are different for the underlying OS and Qt (the library of GUI functions used by the SPM), the month names will not match and the SPM will not be able to extract the expiration date from the information provided by OpenSSL.
L100
The SPM makes a copy of the production database when a user logs in. In MySQL, this is an actual database; in PostreSQL, it is a new schema within the production database. All edits are made on the copy called the Edit Database so that we can evaluate the impact of any changes before we apply those changes to the production database. The actual database name of the Edit Database is spm with the current date/time stamp of the moment we started the login routine in the format yyyyMMddhhmmsszzz where zzz is milliseconds, e.g., spm20030717191123456. The first step in creating the Edit database is to dump the production database to a file on the database server. Whether and how we do this is database dependent, e.g., in MySQL we use mysqldump, whereas it is completely unnecessary in PostgreSQL. This file typically takes a long time to create because it is a list of all the SQL commands needed to recreate the database. We do it this way for both so that we do not have to purchase proprietary faster products in an open source project like SPM (we may do so in the future as a charged add on) and because we must take a snapshop that is sensitive to transactions (e.g., mysqlhotcopy, although faster, is not transaction sensitive).
This error means that we could not make the dump of the production database. The most common cause is an incorrect user name or password since the user must login to the database to make the copy. It could be a lack of disk space on the database server. It could be a database or file system rights issue. It could be a communications breakdown between a remote SPM client and the database server. It could be that the script that launches this dump is corrupt.
L101
Once the production database has been dumped to a file (see error L100), the script running on the database server creates the empty Edit Database (see error L100) with a SQL command similar to "create database spm_spm20030717191123456 ". This error means that the creation of the empty Edit Database failed. It could be a database rights issue. It could be a disk space issue on the database server. It is even possible that a date/time stamp was passed to the script that created an invalid database name. In the case of PostgreSQL, we create the new schema and load the data all in one step using a stored procedure. This error is generated under PostgreSQL if the stored procedure has failed.
L102
Once the empty Edit Database has been created (see errors L100 and L101), the database is filled with the data dumped from the production database. This error means that the script that fills the Edit Database failed. This could be a database rights issue, a disk space issue on the database server or an illegal SQL statement may have been generated in the dump file.
L103
This error means that some unexpected error occurred while creating the Edit Database. This is most likely a communication failure either by loss of network connectivity between a remote SPM user and the database server or a failure to establish an ssh session between the two. If it is an ssh error, it is likely that either the user's key is not listed in the database server's .ssh/authorized key file for that user, the user does not have an account on the database server or the user's computer has not authorized the use of ssh to the database server. It is also possible that the script used to create the Edit Database is missing, corrupt or inaccessible (e.g., insufficient file system rights to run the script); this can happen if the wrong database type is selected from the login screen. It is also possible that the script is not executable.
L104
This error means that we could not open the database. Frequently, the diagnosis is given along with the error such as an invalid user name and password combination, an invalid database name or the database service is not running. It could also be a communications failure between a remote SPM client and the database server.
L105
The Edit Database is dropped when the application exits in order to recover the disk space (which can be substantial). This error is generated when the drop fails. The user is encouraged to manually delete the Edit Database with whatever commands are appropriate to the database being used. The name of the database is given in the error message.
L106
The dump file used to create the Edit Database (see error L100) is deleted at the end of the login sequence to recover the disk space (which can be substantial). This error is generated if the script (which merely deletes the file)writes to stderr. The user is encouraged to manually delete the file named spmdump.sql and is told that it is found on their home directory on the DATABASE SERVER. It is not on their local computer unless their local computer is the database server.
L107 - "Could not open the file <path> DbChanges" - There is a slight possibility that the last database update did not successfully write the string at the end of the DbChanges file that adds the final database version information. During the database update procedure, we commit the changes, obtain the database version (an auto-increment field) from the database and then add this information to the DbChanges file so that we can reconstruct the database in the event of an emergency or a database rollback. This failure would be in an extreme case such as a power failure or dropped network connection at the split second that this addition was being made after the database commit. The login routine checks that the last database update successfully wrote this addition. This error indicates that the login routine could not find the file at all - not just the correct statement at the end. The file could be missing or have inadequate permissions. This is a local file system error so it is not a network issue.
L108 - "Could not open the file <path> DbChanges on <DBD address>" - There is a slight possibility that the last database update did not successfully write the string at the end of the DbChanges file that adds the final database version information. During the database update procedure, we commit the changes, obtain the database version (an auto-increment field) from the database and then add this information to the DbChanges file so that we can reconstruct the database in the event of an emergency or a database rollback. This failure would be in an extreme case such as a power failure or dropped network connection at the split second that this addition was being made after the database commit. The login routine checks that the last database update successfully wrote this addition. This error indicates that the login routine could not copy the file from the DBD. It makes this copy so that, if the entry is missing, it can try to add it and then copy the file back. The problem is it could not obtain the file and not that the correct statement at the end is missing. The file could be missing or have inadequate permissions, it could be a network issue or an SSH issue (SSH not running, incorrect key).
L109 - "The previous database update did not finish properly!" For the context, see L107 or L108. This error means that the dbversion entry was missing from the DbChanges file and we could not add it. No further updates can be made until this error is fixed. It could be a local file issue such as file system rights or it could be a network or SSH issue (SSH not running or invalid key) if this is a remote SPM.
L110 - “Failed to create database password file” - Some databases such as PostgreSQL require that we create a password file to pass in the database user's password as part of the script which creates the edit database (q.v. error L100). This error indicates that the password file could not be created and typically reflects a file creation rights issue on the DBD.
L111 - "Failed to set proper permissions on database password file" - some databases such as PostgreSQL require that we create a password file to pass in the database user's password as part of the script which creates the edit database (q.v. error L100) and that the file has specific permissions. This indicates that the proper permissions could not be set and indicates a file system rights problem on the DBD.
L112 - "Could not access or create local directory: <Data Directory Name>” - the SPM requires a directory under <Installation Path>/data for each database. This error implies the directory is missing or could not be created.
R100 - "I have been previously requested to require one-to-one NAT between <Real Address Range> and <NAT Address Range> The proposed configuration change makes that impossible as there are fewer available NAT addresses than real addresses. I must change the one-to-one NAT to a many-to-some NAT to proceed." The user has created or edited a Best Match enabled resource which has affected a SuperRange. The SuperRange was doing a one-to-one NAT. The new SubRange has excluded enough NAT addresses from the NAT range that there are more Real Addresses than NAT addresses. If it was the other way around, we would just eliminate some of the NAT addresses. However, we cannot eliminate real addresses. Thus, we cannot preserve one-to-one NAT in this case.
R101 - "The new Server IP address <Range> has an unresolvable conflict with the <Service Name> service on <Server Name> on <Resource IP Address Range> In order to create the new server IP address, I must delete the existing conflicting Resource IP address". The user has previously created a Server with a Resource Override which has an IP address range which is a SubRange of one of the Server default IP address ranges. The user is now attempting to create a Server IP address range (through the new or edit functions) which is a SubRange of the existing Server but a SuperRange of the existing Server's Resource Override with the smaller range. We cannot resolve Best Match in this case since the new Server would be simultaneously a SubRange and a SuperRange of the existing Server.
R102 - "The new Resource IP address <Range> has an unresolvable conflict with the server, <Server Name> on <Server IP Address Range> In order to create the new Resource IP address, I must delete the existing conflicting Server IP address". The user is creating a new Resource Override IP address (through the new or edit functions) which is different from the Resource's Server's IP address range. The new Resource Override has an inverse relationship with some other Server IP address range than the relationship the new Resource Override's Server has. For example, perhaps the new Resource Override wants the IP address 10.1.1.5 and lives on a server with an IP address range of 10.1.1.1-10 and there is an existing Server with the IP address range 10.1.1.3-7. The new Resource Override would be a SubRange of the 10.1.1.3-7 Server while the Resource Override's Server is a SuperRange. Since Best Match is established on a Server and not a Resource basis, the Resource Override's Server is not allowed to be simultaneously a SubRange and a SuperRange of 10.1.1.3-7.
R103 - "The new Resource IP address <Range> has an unresolvable conflict with the <Service Name> service on <Server Name> on <Resource IP Address Range> In order to create the new Resource IP address, I must delete the existing conflicting Resource IP address". The user is creating a new Resource Override IP address (through the new or edit functions) which is different from the Resource's Server's IP address range. There is an existing Resource Override which also has a different IP address range from its Server. There is either a conflict between the new Resource Override and the existing Server and Resource Override or between the existing Server and the new Resource Override and its Server or between the existing Resource Override and the new Resource Override and its Server such that the Resource Override and the Server have inverse Best Match relationships with the conflicting IP address range, i.e., one is a SubRange and the other is a SuperRange of the same conflicting address. This cannot be allowed. Please see errors R101 and R102.
R104 - "The new <Resource or Server> IP address <Range> overlaps with the <Service Name> service on <Server Name> on <Resource IP Address Range> In order to create the new <Resource or Server> IP address, I must delete the existing conflicting Resource IP address" or "The new <Resource or Server> IP address <Range> overlaps with the server, <Server Name> on <Resource IP Address Range> In order to create the new <Resource or Server> IP address, I must delete the existing conflicting Server IP address". The new Resource or Server IP address range is an overlap range. This is not allowed since it makes it nearly impossible to sort out the Best Match relationships.
R105 - "Could not retrieve database information for <Resource Group Name>" - This error is exactly as it says - the database could not be accessed. It could be a network communications issue, the database may not be running, it may be corrupt or there may be a database rights issue.
R106 - "Could not commit Resource Group changes" - This is almost identical to R105 except that the error occurred while trying to commit the entire database transaction, i.e., all the changes at once.
U100 - The database has a table named "pep" which stores the information about the name of each PEP and the services it offers. It does not include the external IP addresses of the PEP. Those are stored in a table named "pep_ip_addr" which has a field named "pep" which contains the PEP name. The update thread is passed the name of the PEP from a list based upon the "pep" table. It queries the "pep_ip_addr" database table for all external IP addresses associated with the PEP name. This error is generated if there are no corresponding external IP addresses for the PEP name.
U101 - The SPM opens an SSH session to the PEP to read the contents of the /etc/PEP/dbversion file. This file should contain only a number value. The SPM generates this error if it cannot convert the contents of the file to an Unsigned Integer. This would indicate that the contents contain non-numeric characters or an incredibly large number (larger than an unsigned integer can hold!). One could try to determine the actual database version from the database but this may not be accurate. It would be best to reinitialize such a PEP.
U102 - The database server could not establish an ssh session with the PEP. This could be an invalid key or a breakdown in the network communication.
U103 - "Communication failure to database server" - There is no communication with the database server. It could be that a remote SPM client could not establish an ssh session with the database server. It could be a network problem, an authentication problem such as using the wrong key, an SSH configuration problem or the SSH service may not be running. It could be that the database service is not running. This error also occurs if a remote SPM cannot copy the PEP update files to the DBD in preparation for the DBD to distribute the files. This can be a network, SSH or file system rights problem.
U104 - A PEP can be updated for any of three reasons. 1) A new database is being applied. 2) The PEP was not running the most current database and the user chose to bring it to the current database version outside of a database update. 3) The PEP was not running the most current database and the user chose to bring it to a database older than the current database but newer than the one running on the PEP. In all cases, the data for any of the updates other than the current edit database, i.e., the one being applied in case #1 above, must be pulled from the archives on the database server. The error is generated if there is a failure to retrieve that data. The data may have been deleted, may be corrupted, may be inaccessible (rights issues) or there may be a communications failure between a remote SPM client and the database server. This error is frequently accompanied by another error that will give more specific information.
U105 - The PEP says it has a database version that is greater than or equal to the database to which the SPM is attempting to update it. This should never occur. It is possible that the /etc/PEP/dbversion file on the PEP has corrupted or been manually altered. It is remotely possible that the database counter has looped but the counter should hold a four byte signed integer. When we implement the ability to put a PEP on a non-current database, this error could occur if there was a PEP database version update problem to the production database during a previous update. See error U131.
U106 - The local SPM client needs to write certain files to local disk. These could be copies of the data archives to update a PEP which is not current to some version of the database more current than the one the PEP is using. These could be the files that need to be transferred to the PEP being updated. The failure could be a rights issue or a lack of sufficient disk space. Sometimes this error can be provoked if the files the client is attempting to copy are missing on the database server. This would be a serious error as outlined in error code U113.
U107 - The SPM could not read the files in its dbversions/<database version #> directory. This should never happen since the application had to be able to create them there in the first place. It could also happen when trying to read the pre-configured configuration files found in the data directory in the local SPM data directory, e.g., /usr/local/SPM/data.
U108 - If the SPM is running remotely from the database server, it first spools all the update files for an individual PEP to a local directory (<SPMLocalDataRoot>/PEPfiles/<PEP_Name>/<dbversion#>/). It then copies this entire directory via scp to a similar directory on the database server (<SPMDbDataRoot>/PEPfiles/<PEP_Name>/<dbversion#>/). This error means that the scp failed. This could be a directory rights issue, a missing directory, a ssh rights issue (e.g., bad key), or a breakdown in network communication.
U109 - The database server copies all the configuration changes to the /etc/PEPTemp/directory on the PEP before making any static or dynamic changes. This error indicates that the database server was able to connect to the PEP but the copy of the files failed. This could be a directory rights issue, a disk space issue or, more likely, a breakdown in network communication. It could also be a network communications breakdown between a remote SPM and the database server.
U110 - Before copying in the update files from the database server to /etc/PEPTemp on the PEP, the /etc/PEPTemp directory is cleared in case there are any files left over from a previous update attempt that could interfere with this update attempt. We cannot safely proceed if we fail to clear those files. Instead we generate this error and cease the PEP update.
U111 - This is a critical error. It means that an update attempt failed on a PEP but any already implemented dynamic changes to the PEP during the same update could not be backed out. It is nearly impossible to predict the behavior of such a PEP and it should be reinitialized immediately.
U112 - This is a very serious error. It means that an update attempt failed on a PEP but any already implemented changes to the configuration files during the same update could not be backed out. It is nearly impossible to predict the behavior of such a PEP after a reboot and it should be reinitialized as soon as possible and certainly before the next reboot (which may be unplanned!!!).
U113 - The archive of the changes for the requested database version are missing from the database server. This is a very serious error in that there is no way to recover database changes from before this missing database. Any PEPs that are running older databases than the missing one will need to be reinitialized to be made current and the database base should be reset to start after this missing database version (the ability to reset the base database will probably not be available in version 1.0)
U114 - "Failed to obtain an update lock. Changes cannot be safely committed" - The <SPMDbDataRoot>(currently /usr/local/SPM but soon to be user configurable)/dbversions/updateInProcess file contains the single character "1" when an update is in progress and the single character "0" when an update is not in progress. This functions as a lock since only one update can take place at a time. This error means that the file could not be set to "1". This could be a breakdown in network communications between a remote SPM and the database, an SSH problem in the same scenario or a file rights issue. However, we normally check for the file rights before beginning a commit changes so that would not be normal for this error.
U115 - "Failed to release update lock. No further updates can be applied until this lock is released. To manually release the lock, overwrite the file <SPMDbDataRoot>(currently /usr/local/SPM but soon to be user configurable)/dbversions/updateInProcess on the database server <DB Server IP Address> to contain the single character "0"" This is a self explanatory message. For the technical background, please see error code U114.
U116 - "Could not create the directory . . ." - the SPM writes the DbChanges first to a file in a directory named after a time stamp and then renames that directory to the database version number when the database version number has been confirmed. It also writes temporary files for archive files needed for updating PEPs to a database version other than the current edit database. This error means we could not create the directories to hold these files. Since this is an action on the local file system, it is probably a file system rights issue or a disk space issue.
U117 - "Could not remove old file <file pathname>" - the SPM temporarily writes all of the PEP configuration files to a local directory. Those writes are always appends so that it can extract one file from several QStringList entries writing each QStringList entry as it encounters it while parsing the List. Thus, we always check to see if the file exists before the first write and delete it if it does so that it does not inject spurious information into the new file. This error means that we found such an old file and could not delete it. It is probably a file rights issue as these are always local files.
U118 - "Could not write local file <file pathname>" or "Could not write to the directory <directory name> - the SPM temporarily writes all of the PEP configuration files and a copy of the database changes (DbChanges) to a local directory. This error is a failure to write those files. Since these are local files, it is almost certainly a file system rights or disk space issue.
U119 - "The database version information could not be saved" - at the very end of saving all the changes to the database, the database changes must be stamped with the final dbversion. This contains a version number generated by the database and a date/time stamp. This error means that we could not write the database entry for the new dbversion. Without it, we cannot reconstruct the database or update PEPs that are not up that database version. Therefore, this problem provokes a rollback of the database transaction, i.e., no changes will be saved if this error occurs. Changes are not lost. An attempt may be made to recommit them.
U120 - "The database version comment could not be saved" - This indicates a failure to write to the database. It could be a network communications issue if running a remote SPM, a database issue, e.g., the database service is not running, or a database rights issue. The error is non-critical and does not stop the update process.
U121 - "The update files could not be transfered to the <DBD update file area> directory on DBD <DBD IP Address>" - If we are running a remote SPM, the update files created are the local file system. Before they can be transferred to the PEPs, they must be copied via scp to the DBD. This error indicates that the copy failed. It could be a network communications failure, as SSH failure (bad key, SSH not running on the DBD) or a file system problem on the DBD (low disk space, file system rights problem). The update cannot continue until it is rectified.
U122 - "Could not delete the local temporary files in <Local update file area)" - for context see error U121. This is a non-critical error that says the local temporary files could not be deleted. This should not occur since the same user and application created them in the first place. The files should be manually deleted to recover the disk space.
U123 - "Could not rename the <temporary update directory pathname> directory to <permanent update directory pathname>" - Since it is possible that another user has made a database update since the current user started their update, we give the update file directory a temporary name until we can definitively establish the database version number. Once we have established the database version number, we rename the temporary directory. This error indicates that the rename operation failed. If this is a remote SPM, it could be a network communications problem or an SSH problem (SSH not running or an invalid key). For either a remote or local SPM, it could be a file rights issue. although that is unlikely on a local SPM since the same user and application created the files in the first place.
U124 - "Could not write the statement <a SQL statement> to the end of <a file pathname> on <the DBD IP Address>. The DBD contains a copy of all the SQL statements that have updated the database. This is so that the database can be reconstructed. This is important for both disaster recovery and to roll back to a previous database version. The very last statement that updates the database version number is made after the DbChanges file (the file that records the changes) is written to the DBD. This SQL statement must be appended to the end of the file. This error results when we are unable to append the SQL statement to the file. It is important that the changes be made manually but does not halt the update.
U125 - "Could not retrieve PEP list" - The SPM queries the database for a list of all PEPs as it is about to distribute updates. This error is provoked when the SQL query fails. The problem could be a network communications issue if this is a remote SPM. It could be a database service issue such as the service not running or the needed records arre locked. It could be a database rights issue. The update cannot continue.
U126 - "Unable to change group ownership of the <directory name> directory and its files on <DBD IP address> to SPM" - The group ownership of the update files (e.g., DbChanges, FWChanges) must be changed to "SPM" so that files created by one remote SPM user can be used by a different remote SPM user. This error indicates that the SPM failed to change the group ownership from the default group of the current user to the SPM group. The change should be made manually by the file system administrator of the DBD. Otherwise, other remote users may not be able to read the update files. If this is the case with DbChanges, the other remote users will not be able to start an edit session since DbChanges must be read and possibly updated by the next user.
U127 - "Unable to change access to the <directory name> directory and its files on <DBD IP Address> to full rights for owner and the SPM group"-The access rights of the update files on the DBD should be changed so that the owner and the SPM group have full access to them and no one else does. When they are first created, the user has full access, the group and everyone else has read and execute access. The SPM changes these access rights. This error indicates that the SPM failed to do so.
U128 - "Unknown port(s) <port numbers> for IP protocol <IP protocol number>" - this error should never occur. It means that port numbers were passed to the firewall for protocols that do not understand port or type numbers.
U129 - "Certificate missing from database for file <filename>" - This error should never occur. It means that there is a record in the database for the Certificate Authority contained in this file but there is no corresponding certificate in the database. This would either be a logic error in the SPM or corruption in the database.
U130 - "Could not copy the firewall rules for <PEP Name> to the DBD" - If the SPM is running remotely from the database server, it spools the static firewall rules files for an individual PEP to a local directory (<SPMLocalDataRoot>/dbversions/<database version>/<PEP_Name>/). It then copies this entire directory via scp to a similar directory on the database server (<SPMDbDataRoot>/dbversions/<dbversion#>/<PEP_Name>/). This error means that the scp failed. This could be a directory rights issue, a missing directory, a ssh rights issue (e.g., bad key), or a breakdown in network communication.
U131 - "The PEP Database Version for <PEP Name> could not be saved to the database. The PEP and database will synchronize on the next successful update or you can use the verify PEP DBVersion function. This is a typical database communications failure however it means that the "current status" and database version in the database does not reflect the actual status of the PEP. The next update which affects this PEP will synchronize the two since the update routine uses the database version on the PEP and not in the database. The database versions can also be reconciled by using the verify PEP DBVersion function but this may not reconcile the "current status" flag, i.e., the notation of whether or not the PEP has the most current database that pertains to it. Not every database update applies to every PEP thus a PEP may be current and yet have a database version lower than the most recent SPM database. The current status will only be accurate if the most recent SPM database version is indeed the current PEP database version. The only non-cosmetic problem this causes is if the user attempts to advance the database to a version which is less than current, less than the version on the PEP and greater than the version the database thinks the PEP has. In that case, the update will fail with a U105 error. This functionality will not be available in SPM version 1.x.
U132 - "Failed to translate NetNAT addresses" – There was a problem translating addresses using Internal Network Address translation (e.g., mapping an entire internal network to another intern network perhaps because of IP address conflicts) back to their original addresses for the PEP hosting the translated network. The hosting PEP must know the Resources by their native address while all the other PEPs know them by their translated addresses. There was a problem converting back during while preparing the update files.
U133 - "I was not able update the edit database so I must load a new copy" – The SPM maintains the current base number or ResIDs and ChainNumbers. After each update, these are fetched from the Production database so they are current. This error indicates there was a problem retrieving the data and so the SPM will attempt to reload a new copy of the Production database from which to make its edits.