Previous
Index Next
ISCS version 0.1.1
It is possible that a previous update set the contents of the updateInProcess file on the database server (in the initial release this is /usr/local/SPM/data/updateInProcess and in future versions will be found in the directory specified in the user configurable setting "Database Server Update Data Directory") to the single character "1" and then did not reset it to "0" when finished or the file is missing. If one is sure that truly no updates are in process, change the contents of this file from "1" to "0" (without the quotation marks) or, if the file is missing, create a new one with the contents set to the single characer "0".
This error could also be provoked by lost IP connectivity to the database server so that it cannot open the updateInProcess file but that should manifest itself in other problems besides just this one. If we have lost network connectivity, every single database call will fail as well.
The Database calls and the ssh calls have very long time outs. If there is a communications breakdown between a remote SPM and a DBD or even a database failure on a local SPM, the SPM may appear hung. It should eventually generate an error message and recover. SSH timeouts will generally be between 45 and 180 seconds depending on whether or not the user allowed the installation routine to reduce the default number of tcp retries. The database timeouts may be several minutes long.
Sometimes the SPM database timeout may be longer than the timeout of the database connection itself. In that case, even if the SPM recovers, the database connection may be lost and the user will need to logout and login. This will result in the loss of any uncommitted changes.
We occasionally had ssh problems in the test lab between a remote SPM and a very slow DBD (486/66 with 128 MB of RAM). The normal user would not be given a proper ssh session. If attempted from the command line, the shell would generate a fork error. We resolved the problem by rebooting the DBD.
The ability to NAT a network is essential for resolving conflicting IP address space. However, it does have some limitations. For example, although the network traffic will flow freely, name resolution is a problem. Those network using the real address, e.g., the physical network itself, must use a name resolution service (DNS, WINS, etc.) that provides the real, unNATted address. Those networks using the NAT address must use a name resolution service that provides the NATted addresses.
Even with proper name resolution, Accessors on a network which is NATted to the rest of the WAN will not be able to access resources on another network with the same address as their real address. For example, let's say that behind PEPA we have network 10.1.1.0/24 which is NATted to the rest of the WAN as 172.16.1.0/24. Behind PEPB we have network 10.1.1.0/24 which is known to the rest of the WAN by its real address, i.e., 10.1.1.0/24. Accessors behind PEPC will be able to reach resources behind PEPB by addressing them as 10.1.1.0/24 and resources behind PEPA by addressing them as 172.16.1.0/24. Accessors behind PEPB can access resources behind PEPA by addressing them as 172.16.1.0/24. However, Accessors behind PEPA cannot access resources behind PEPB by addressing them as 10.1.1.0/24 because the packets will be assumed to live on the 10.1.1.0/24 network behind PEPA and not PEPB.
A possible solution is to also NAT the 10.1.1.0/24 network behind PEPB. This way, no network on the WAN is known as 10.1.1.0/24.
NAT Internal Local only works between networks on different interfaces of the PEP. Specifically, the packets must pass through the PEP (in order for the PEP to take any action on them) and they must pass from one interface to another (as opposed to different virtual networks on the physical interface). Thus, activating NAT Internal Local on a PEP with only one private interface is meaningless.
Internal NAT will not work for protocols that cannot use NAT at all. For example, some protocols may embed IP address information in the data portion of the packet. Unless the NAT routine understands this protocol and also changes the information in the data, there is a good chance the protocol will not function properly when NATted. The packets may not be properly understood at the data layer even though the packets can be delivered at the network layer or the reply packets may be erroneously addressed by the application. For example, if we NAT 10.1.1.1 to 1.1.1.1 and send the packet across the Internet to ApplicationZ and ApplicationZ embeds the source address in the data portion of the packet, ApplicationZ may look in the data portion of the packet for the IP address to which to send the reply packet. If it uses the information in the data portion rather than the information in the network layer, it will address the reply packet to 10.1.1.1. The reply packet will not be able to traverse the Internet.
NAT is not to be confused with Access Control. For example, if the administrator mandates that the ISCS should NAT a private address to a public address, that does not automatically give the private address permission to access the Internet. It merely allows the technical feasibility by telling a PEP to translate the address IF it receives an allowed packet. The administrator would still have to grant the private address access to the Internet to allow the packets to get to the NAT module in the first place.