Changing the IP Address

Release Notes
- SAKA 4.12.0
- SAKA 4.11.0
- Back
Preface
- Default Paths and Filenames
- Third-Party Website References
- Strongkey Welcomes Your Comments!
- Back
KAM Introduction
Architecture
Installation
- Preliminary Steps
- Install Components (Primary)
- Install Components (Secondary)
- Define KCs (Primary)
- Verify KCs (Secondary)
- Set Personal Identification Numbers (PINs) [Primary]
- Set PINs and Complete Key Migration [Secondary]
- Create System Users [Primary]
- Create a New Encryption Domain [Primary]
- Complete Second Domain Key Migration [Secondary]
- Add System Users [Primary]
- Configure the SKCE domain [Primary]
- Replicate the CEM Domain [Secondary]
- Back
CCS Web Service Operations
- CCReturnObject
- Manufacturer Identifiers for Processing CardHolder Data (CHD)
- CCS Module GetCardCaptureData Mechanics
- CCS Module DukptEncrypt Mechanics
- CCS Module DukptDecrypt Mechanics
- CCS Module DukptMAC Mechanics
- CCS Module ReencryptPINBlock Mechanics
- Back
KAM Web Service Operations
- KAM Encryption Mechanics
- KAM Decryption Mechanics
- Notes on the Mechanics
- KAM Deletion Mechanics
- KAM Search Mechanics
- KAM Entropy Mechanics
- KAM General Purpose Key Encryption Mechanics
- KAM General Purpose Key Decryption Mechanics
- KAM Batch Operations
- KAM Relay Mechanics
- HTTPS Interface
- SOAP Interface
- Back
KMS Web Service Operations
- CCReturnObject
- CCKeyComponentType
- CCCryptographicMaterialType
- CCEncryptedAnsiX9241KeyType
- KMS Module loadKeyComponent Mechanics
- KMS Module loadBaseDerivationKey Mechanics
- KMS Module generateBaseDerivationKey Mechanics
- KMS Module generateInitialKey Mechanics
- KMS Module storeAnsiX9241Key Mechanics
- KMS Module replaceAnsiX9241Key Mechanics
- KMS Module deleteAnsiX9241Key Mechanics
- KMS Module updateAnsiX9241Key Mechanics
- Back
KAM Batch Operations
- SKLESBatchInput Element
- SKLESBatchOutput Element
- Generating the SBI XML file
- Transferring XML Files to and from the Appliance
- Submitting Batch Operations
- Back
KAM DemoClients
- Installing SAKA Clients
- sakaclient.jar Operations
- Back
KAM KCSetPINTool
- Setting KC Preferences
- Changing KC Passwords
- Setting the KC PIN on the SAKA Server
- Back
KAM DACTool
- Changing DA Passwords
- Preferences
- Systems
- Domains
- Users
- Jobs
- Configuration
- Back
KAM Key Migration Tool
- Prerequisites
- Back
KAM KMS ConsoleTool
- Loading Key Components
- Loading a BDK
- Storing ANSI X-924.1 Keys from Key Components
- Storing ANSI X-924.1 Keys from Wrapped Keys
- Back
KAM Configuration
- Immutable Configuration
- Mutable Configuration
- Sample Configuration File
- Back
KAM Key Management
- Cryptographic Hardware Modules
- Back
HSM Integration
- Building the HSM Driver
  - Rebuilding the HSM Driver
  - Back
- HSM Administration Basics
- Clearing the HSM
- Setting Up the HSM
- Backing up the HSM
- Restoring from a Backup
- Back
Managing Credentials
- KAM Credentials
- HSM Credentials
- System Credentials
- Linux strongauth
- Back
Changing Hostname and IP
- Changing the IP Address
- service iptables restart
- Changing the Hostname
- Back
Internal Repositories
- Repository Requirements
- Choosing an Online Mirror
- Internal Repository Setup
- KA Setup
- Back
Appliance Security
- Physical Security
- Operating System
- Appliance Credentials
- Back
PCI DSS 3.2
- Requirement 3: Protect Stored Cardholder Data
- Requirement 6: Develop and Maintain Secure Systems and Applications
- Back
KC Responsibilities
Add New SKCE Domain
KAM Replication
- Replicate Essentials Only
- Back
Appendices
- Using a Custom Trust Store
- Using the Key Migration Tool (KMTool)
  - Pre-requisites
  - Mechanics
  - Details
  - Back
- Modifying the Appliance's IP Address or Hostname
- Relay Webservice
  - Mechanics of the Relay
  - Deploying the service
  - Relay Webservice Client
  - HTTP interface
  - SOAP interface
  - Back
- Installing KCSPTool and DACTool on Windows
  - Installation
  - Back
- KAM KC Replace Tool
  - Prerequisites
  - Validating Credentials
  - Recreate a set of Key Custodians
  - Create a new set of Key Custodians
  - Back
- Migration Information
- Using HAProxy as a Load Balancer
- MariaDB Audit Logging Configuration
  - Enable MariaDB Audit Logging
  - Monitoring the MariaDB for Replication anomalies
  - Disable MariaDB Audit Logging
  - The counts_v2.sql file
  - Back
- Application Development Guide
  - Application Design for “Card Not Present” transactions
  - Storing Encryption Domain Identifier (DID)
  - Securing Decryption Credentials
  - Cluster Communications
  - Relay Processing
  - Summary on “Card Not Present” transactions
  - Back
- Setting up LACP Bonding on Tellaro KA
- Strongkey Tellaro & Ransomware Protection
- Adding an Additional Server to a Cluster
  - Step #1 on an EXISTING server
  - Step #2 on the NEW server
  - Step #3 On the EXISTING node
  - Step #4 on the NEW node
  - Back
- Adding a Data Recovery Server to a Cluster
  - Step #1 on an EXISTING server
  - Step #2 on the NEW server
  - Step #3 on the EXISTING node
  - Step #4 on the NEW node
  - Post-Installation
  - Back
- Batch Delete Tokens
- CIS Hardening Verification RHEL 7.X
- CIS Hardening Verification ROCKY 9.X
- Migrating from Centos to Rocky
  - Rocky Linux Kickstart USB Guide
  - Step 1: On an Existing Production Server in the Cluster
  - Step 2: On the Same Machine after Installing Rocky 9.2
  - Back
- KA Replace EOL Node
  - Prerequisites
  - Step 1 (On New SAKA)
  - Step 2 (On EOL SAKA)
  - Step 3 (On New SAKA)
  - Step 4 (On EOL SAKA)
  - Step 5 (On New SAKA)
  - Step 6 (On EOL SAKA)
  - Step 7 (On New SAKA)
  - Back
- Cleanup SAKA Disk Space
  - Cleanup Old Distributions and Files
  - Cleanup Database Tables
    - Cleanup Encryption Requests Table
    - Back
  - Back
- Using Custom SSL/TLS Certificates
  - Generating a TLS certificate with the SAN extension
  - Installing the keystore on SAKA
  - Conclusion
  - Back
- Reboot StrongKey Tellaro
  - Pre-Reboot
  - Reboot
  - Post-Reboot
  - Back
- Configure Syslog
- Back

Before starting these steps, ensure no traffic is being sent to the SAKA having its IP Address changed. This process will stop Payara on that node, change the networking configuration on that node, change the firewall configuration on every other node, reboot the node, and afterwards restart Payara on all other nodes. Before starting this process, be sure a plan is pared for restarting each node (one at a time is fine).

To change the IP address after the appliance is in production, perform these tasks:

Login as root into the appliance—either on the console or using Secure Shell (SSH).
Stop Payara with the following:
```
service glassfishd stop
```
Update your DNS master to reflect the new TCP/IP address of the appliance, then propagate it to the network. Verify that the new address is visible using dig on Linux or nslookup on Windows and UNIX-like operating systems. Alternatively (or additionally), update the /etc/hosts file on all SAKA servers in the cluster to update the IP Address for this host.
If using static TCP/IP address—which is strongly recommended—make a copy of the /etc/sysconfig/network-scripts/ifcfg-em1 file (in case it becomes necessary to reverse your changes).
This file may alternatively be called /etc/sysconfig/network-scripts/ifcfg-eth0 depending on the hardware in your appliance.
Edit the ifcfg-eth0 or ifcfg-em1 file with a text editor and modify the GATEWAY, IPADDR, and NETMASK variables with values corresponding to the new TCP/IP address. Save the file.
On all other SAKA servers in the cluster, update the firewall /etc/sysconfig/iptables and update the IP Address in the configuration to match the new IP Address. When finished, restart the firewall to persist the changes: