Here is a breakdown of the ports that must be opened in a firewall for use with NIM: Have a large physical volume (200+ GB) for nim. Create a volume group for nim. Usually something like nimvg, like the jfs2 file system. Particular attention should also be paid to the MNI. NIM must be configured for NFS, bootp (or dhcp), and tftp. NIM communication itself also requires special open ports for proper communication. This link gives a good breakdown of NIM and especially ports that require special firewall rules. The nimsh client daemon listens on these ports for requests initiated by the master via TCP. The primary port listens for service requests on reserved port 3901. When a request is accepted, the primary port is used for stdin and stdout requests.
Stderr requests are redirected to secondary port 3902. This behavior is similar to helper connections in rcmd(). This implementation allows the NIM back-end connection to remain consistent with current support for client connections through the rsh command. Using a reserved secondary port in NIMSH allows firewall administrators to write firewall rules to accept incoming connections on privileged ports from the secondary port. These rules may require that the original socket address (host name: secondary port) be from a trusted source. TechNote: The information in this document applies to NIM at AIX 5.x through AIX 7.1. What is covered and what is not covered in this document: Covers: – Introduction to NIM Service Manager or `nimsh` – The installation process – The cleaning process – The protocols and ports used by these protocols during a network installation – Distribution of ports that must be opened in a firewall for use with NIM – Other firewall considerations Does not cover: – Detailed description of NIM or `nimsh` service manager – Instructions for performing network installations – Steps to detect or debug problems for failed network installations Introduction to NIM Service Manager or “nimsh”: For AIX 5.2 Technology Level 7, AIX 5.3, AIX 6.1 and AIX 7.1, an additional optional service called “nimsh” or NIM service handler has been added. For environments where standard rsh protocols are not sufficiently secure, nimsh can be implemented. The client daemon has two ports registered with the Internet Assigned Numbers Authority (IANA) for use during network communication. With nimsh, the primary port used by the client is 3901 and listens for service requests.
The primary port on the client is used for stdin and stdout, while stderr is redirected to secondary port 3902. **For more information about nimsh, refer to the publib.boulder.ibm.com/infocenter/pseries/index.jsp section in the AIX 5.3 documentation and search for nimsh. Installation Process The installation overview provides a brief summary of the installation process. This section briefly describes client/server communication during an NIM installation. The “push” and “pull” installations are briefly described. Master-initiated installation – also known as push installation When a network installation is initiated by the master master, the NIM master prepares the resources for installation. When the master prepares its resources, it creates script files, exports NFS resources (lpp_source, mksysb, and so on), populates the /etc/bootptab file, populates the /tftpboot directory, and then runs an rsh command on the client to set the startup list to install on the network interface. The client resets and attempts to boot to the network using the bootp and tftp services.
Client-initiated installation – also known as a pull installation When a network installation is initiated from the client endpoint, the NIM master always prepares its resources for installation as if it were a push installation. The difference is that during a pull installation, the NIM master does not run an rsh command to set the client`s startup list and then reset it to boot from the network. The /etc/bootptab file and the /tftpboot directory continue to be populated with script files created and NFS resources exported. Post-installation cleanup process After the installation is complete, the client sends status information about the `nimclient` calls to the master`s Nimesis daemon. The NIM master then unallocated all installation resources for the client object that completed the installation. The move process consists of: 1. Deleting files from the specified tftp directory – Deleting client.info file – Removing the link to the boot image – Removing the file entry in /etc/bootptab 2. Cancel export of client nfs resources – Remove entries from /etc/exports – Export remaining entries from /etc/exports 3. Update client object information in NIM database – Computer state — running – or not running – command result — success -or- error – client status — ready for operation -or- not running Protocols used during a network installation When a network installation is performed, several protocols involved. The following overview should provide the appropriate steps to determine firewall management tasks: Installation Overview NIM performs network installations using a client/server model based on bootp/tftp protocols to receive a network boot image.
After the boot image is obtained, the client (using tftp) requests a configuration file (client.info) to determine which server contains the installation image and other required installation resources. The installation image and resources are mounted on nfs using nfsd/mountd services. After all mounts are successful, the installation begins and subsequent information is sent via nimclient calls to the nimclient daemon (nim) to the NIM master. RSH stdin/stdout: `rsh` requires clients to connect through source ports. There is a reserved port range for `rsh` communication, and the port range for `rsh` communication is 1023-513. Because NIM clients do not have customer service, clients communicate by calling `rcmd()`. This command then calls rreservport(), which creates a TCP socket. When the TCP socket is created, it binds a port in the privileged port range 1023-513. The port is determined by initializing the boot port (1023) and trying to bind it. If the attempt to bind to port 1023 fails, an attempt to bind to the next port is made in descending order (1022, then 1021, and so on) until a successful connection to an unused port copy is secured.
If no attempt succeeds after finally reaching port 513, the process results in a global error. stderr: The rcmd() command allows you to bind a secondary or additional port to any stderr. If this option is set, rreservport() is called again, but this time the boot port is based on the source port we got in the previous step. The same method is used to find the nearest open port. Source – 1, in descending order, until a successful connection to an unused port copy is secure. The secondary port listens for all stderrs received from the target service.
