Member since
01-19-2017
3682
Posts
633
Kudos Received
373
Solutions
My Accepted Solutions
| Title | Views | Posted |
|---|---|---|
| 1722 | 06-04-2025 11:36 PM | |
| 2161 | 03-23-2025 05:23 AM | |
| 1033 | 03-17-2025 10:18 AM | |
| 3956 | 03-05-2025 01:34 PM | |
| 2705 | 03-03-2025 01:09 PM |
03-05-2025
01:34 PM
2 Kudos
@pavanshettyg5 The TLS implementation for NiFi requires proper configuration of both keystore and truststore your organization's signed certificate with SAN entries to enable secure HTTPS access. Based on your description, you've received a signed certificate (nifi.crt) but are experiencing issues with the complete TLS setup. Required Certificates & Files Certificate Authority (CA) Certificate: The root certificate from your signing authority Truststore: Contains the Certificate Authority (CA) root/intermediate certificates that signed your NiFi certificate (for mutual TLS or cluster communication). Signed Certificate (nifi.crt): Your domain certificate with the SAN entries Private Key: The private key used to generate the CSR 1. Prepare Certificate Files Ensure you have: The signed certificate (nifi.crt) Your private key The CA certificate (request from your CA if not available) Problem 1: Missing Private Key or Certificate Chain If you only have nifi.crt, you must also have: The private key (e.g. nifi.key) generated during the CSR process. The CA root/intermediate certificates (if your organization uses a private CA). Problem 2: Improper Keystore/Truststore Format NiFi uses Java KeyStores (JKS or PKCS12). Ensure your keystore/truststore is in the correct format. If your organization uses OpenSSL-based tools, convert the PEM files (nifi.crt + nifi.key + CA chain) into a PKCS12/JKS keystore. Problem 3: SAN Entries Not Recognized Verify the SAN entries in your certificate match the NiFi node hostnames (e.g. nifinode1.x.x.net). Use openssl x509 -in nifi.crt -text -noout to check SANs. 3. Step-by-Step Solution A. Prepare the Keystore Combine Certificate and Private Key: If you have nifi.crt and nifi.key, create a PKCS12 keystore: openssl pkcs12 -export \ -in nifi.crt \ -inkey nifi.key \ -chain -CAfile ca_chain.crt \ # Include CA chain if needed -name "nifi" \ -out nifi-keystore.p12 -password pass:keystorepassword Use a password (e.g., keystorePassword). 2. Convert to JKS (if required) Java Keystore from PKCS12 keytool -importkeystore \ -srckeystore nifi-keystore.p12 \ -srcstoretype PKCS12 \ -destkeystore nifi-keystore.jks \ -deststoretype JKS B. Prepare the Truststore Import CA Certificates: If your organization uses a private CA, add its root/intermediate certificates to the truststore keytool -import -trustcacerts \ -alias ca-root \ -file ca_root.crt \ -keystore nifi-truststore.jks C. Configure NiFi Update nifi.properties # HTTPS Settings nifi.web.https.host=0.0.0.0 nifi.web.https.port=9443 nifi.web.https.network.interface.default= # Security Properties # nifi.security.keystore=/path/to/keystore.jks nifi.security.keystoreType=JKS nifi.security.keystorePasswd=keystorepassword nifi.security.keyPasswd=keystorepassword nifi.security.truststore=/path/to/truststore.jks nifi.security.truststoreType=JKS nifi.security.truststorePasswd=truststorepassword # Truststore (required for cluster nodes/ZooKeeper) nifi.security.truststore=./nifi-truststore.jks nifi.security.truststoreType=JKS nifi.security.truststorePasswd=truststorePassword # Enable TLS for cluster nodes nifi.cluster.protocol.is.secure=true nifi.web.http.port= nifi.web.https.port=9443 nifi.zookeeper.connect.string=zookeepernode1.x.x.net:2181,zookeepernode2.x.x.net:2181,zookeepernode3.x.x.net:2181 nifi.zookeeper.client.secure=true 2. Updateauthorizers.xml (for mutual TLS): Configure for Cluster Communication Configure authorizers.xml and nifi-registry.properties for secure cluster communication using the same certificates. <property name="Initial Admin Identity">CN=admin, OU=YourOrg</property> <property name="Node Identity 1">CN=nifinode1.x.x.net, OU=YourOrg</property> D. Validate the Setup After configuration Test Keystore/Truststore: # Verify keystore contents keytool -list -v -keystore keystore.jks -storepass keystorepassword # Verify truststore contents keytool -list -v -keystore truststore.jks -storepass truststorepassword # Test SSL configuration openssl s_client -connect nifi-dev.x.x.net:9443 -showcerts Troubleshooting Common Issues Certificate Chain Issues: Ensure your keystore includes the full certificate chain # Concatenate certificates if needed cat nifi.crt intermediate.crt root.crt > fullchain.crt SAN Validation: Verify certificate has correct SAN entries openssl x509 -in nifi.crt -text -noout | grep -A1 "Subject Alternative Name" Java Compatibility: Ensure Java version compatibility with TLS # Add to bootstrap.conf if using older Java versions java.arg.16=-Dhttps.protocols=TLSv1.2 Cluster Communication: Set proper node identities for cluster # In nifi.properties nifi.cluster.node.address=nifinode1.x.x.net nifi.cluster.node.protocol.port=11443 nifi.remote.input.secure=true ZooKeeper Security: Only if using secure ZooKeeper connections # In zookeeper.properties secureClientPort=2281 serverCnxnFactory=org.apache.zookeeper.server.NettyServerCnxnFactory ssl.keyStore.location=/path/to/keystore.jks ssl.keyStore.password=keystorepassword ssl.trustStore.location=/path/to/truststore.jks ssl.trustStore.password=truststorepassword Verify HTTPS Access: Access https://nifi-dev.x.x.net:9443/nifi in a browser. Use curl -vk https://nifi-dev.x.x.net:9443/nifi to debug TLS handshake errors. 2. Troubleshooting "SSL Peer Unauthenticated": Ensure the truststore contains the CA certificate that signed the NiFi certificate. "Certificate Doesn't Match Hostname": Verify SAN entries in nifi.crt include all NiFi node hostnames. Keystore Password Mismatch: Ensure nifi.security.keystorePasswd and nifi.security.keyPasswd match in nifi.properties. Additional Recommendations Use strong, unique passwords for keystores and truststores Implement proper certificate rotation procedures Consider automating certificate management with tools like cert-manager Implement client certificate authentication for additional security Ensure proper DNS resolution for all SAN entries By following the above steps, you’ll enable HTTPS for NiFi with proper SAN support and resolve keystore/truststore issues Happy hadooping
... View more
03-05-2025
10:30 AM
@Rich_Learner To resolve the issue where the ttype column returns NULL and subclasses' values aren't being parsed correctly, follow these steps: 1. Case Sensitivity in JSON Paths The JSON keys Type and ProductCOde use uppercase letters. Correct the paths in get_json_object to match the exact case: Use '$.Type' instead of '$.type'. Ensure '$.ProductCOde' matches the case in the JSON (if it's a typo, adjust accordingly). 2. Properly Handle Nested Arrays Avoid flattening both the outer products array and inner Offer array into the same lateral view. Use separate lateral views for each array level. Corrected Code WITH product AS ( SELECT xml_data, GET_JSON_OBJECT(xml_data, '$.Customer.CustomerId') AS applicationid, -- Extract products array as a JSON string GET_JSON_OBJECT(xml_data, '$.Customer.products') AS products_json FROM Custome_info ), -- Explode the products array exploded_products AS ( SELECT applicationid, product_item FROM product LATERAL VIEW OUTER EXPLODE( SPLIT( REGEXP_REPLACE( REGEXP_REPLACE(products_json, '^\\[|\\]$', ''), -- Remove outer brackets '\\}\\,\\{', '\\}\\;\\{' -- Split products ), ';' ) ) p AS product_item ), -- Explode the Offer array within each product exploded_offers AS ( SELECT applicationid, GET_JSON_OBJECT(product_item, '$.ProductCOde') AS ProductCode, GET_JSON_OBJECT(product_item, '$.Type') AS ttype, offer_item FROM exploded_products LATERAL VIEW OUTER EXPLODE( SPLIT( REGEXP_REPLACE( REGEXP_REPLACE( GET_JSON_OBJECT(product_item, '$.Offer'), '^\\[|\\]$', '' -- Remove inner Offer brackets ), '\\}\\,\\{', '\\}\\;\\{' -- Split Offer items ), ';' ) ) o AS offer_item ) -- Combine results (products and their offers) SELECT applicationid, COALESCE( GET_JSON_OBJECT(offer_item, '$.ProductCOde'), -- Offer-level ProductCode ProductCode -- Product-level ProductCode ) AS ProductCode, COALESCE( GET_JSON_OBJECT(offer_item, '$.Type'), -- Offer-level Type ttype -- Product-level Type ) AS ttype FROM exploded_offers; Explanation Case Sensitivity Fix: Using '$.Type' ensures the correct extraction of the Type field from the JSON. Nested Array Handling: First, explode the products array to get individual product objects. Then, explode the Offer array within each product to access sub-offer details. Combined Results: Use COALESCE to merge product-level and offer-level values into a single output, ensuring both levels are represented. Expected Output ApplicationID | ProductCode | ttype 19900101 | ABC | C1 19900101 | A1 | CBA 19900101 | A2 | DBA 19900101 | A3 | BBA 19900101 | XYZ | C2 19900101 | B1 | BBA 19900101 | B2 | BBA Happy hadooping
... View more
03-03-2025
01:09 PM
@pavanshettyg5 But looking at the error messages when running zkServer.sh status on the ZooKeeper nodes: on zookeepernode1 and 2, there's a message: "Client port not found in static config file. Looking in dynamic config file." Then a grep error: "grep: : No such file or directory". This suggests that the static zoo.cfg is missing the clientPort entry, and the dynamic configuration file (which is probably specified via dynamicConfigFile in zoo.cfg) is either not present or misconfigured. To resolve the ZooKeeper and NiFi connectivity issues, follow these steps and hopefully that will resolve your nifi connectivity issue Step 1: Configure ZooKeeper to Bind to All Interfaces Problem: ZooKeeper nodes are binding to localhost, preventing remote connections from NiFi. Fix: Update zoo.cfg on each ZooKeeper node to bind to 0..0.0.0 (all interfaces). 1. Edit zoo.cfg on each ZooKeeper node: vi /opt/zookeeper/conf/zoo.cfg 2. Add/Modify these lines clientPort=2181 clientPortAddress=0.0.0.0 3. Restart ZooKeeper on each node: /opt/zookeeper/bin/zkServer.sh restart Step 2: Verify ZooKeeper Configuration After restarting, check the status /opt/zookeeper/bin/zkServer.sh status Expected Output: Client address: 0.0.0.0(not localhost). One node should beleader, others follower. Step 3: Check ZooKeeper Network Connectivity From NiFi nodes, test connectivity to ZooKeeper: telnet zookeepernode1 2181 telnet zookeepernode2 2181 telnet zookeepernode3 2181 If connections fail, check firewalls/security groups to allow traffic on port 2181. Step 4: Validate ZooKeeper Dynamic Configuration (If Applicable) If using dynamic reconfiguration: 1. Ensure the dynamic config file (e.g., zoo_dynamic.cfg) has entries like server.1=zookeepernode1:2888:3888:participant;zookeepernode1:2181 server.2=zookeepernode2:2888:3888:participant;zookeepernode2:2181 server.3=zookeepernode3:2888:3888:participant;zookeepernode3:2181 2. Confirm the static zoo.cfg references the dynamic file: dynamicConfigFile=/opt/zookeeper/conf/zoo_dynamic.cfg Step 5: Verify NiFi Configuration Ensure nifi.properties points to the correct ZooKeeper ensemble: nifi.zookeeper.connect.string=zookeepernode1:2181,zookeepernode2:2181,zookeepernode3:2181 Step 6: Restart NiFi Services Restart NiFi on all nodes: /opt/nifi/bin/nifi.sh restart Check logs for successful connections: tail -f /opt/nifi/logs/nifi-app.log Troubleshooting Summary ZooKeeper Binding: Ensure ZooKeeper listens on 0.0.0.0:2181, not localhost. Firewall Rules: Allow traffic between NiFi and ZooKeeper nodes on ports 2181, 2888, and 3888. Hostname Resolution: Confirm zookeepernode1, zookeepernode2, and zookeepernode3 resolve to correct IPs on NiFi nodes. By addressing ZooKeeper's binding configuration and network accessibility, NiFi should successfully connect to the ZooKeeper cluster. Happy hadooping
... View more
03-02-2025
07:19 AM
@drewski7 The error message says there's no EntityManager with an actual transaction available. That suggests that the code trying to persist the user isn't running within a transactional context. In Spring applications, methods that modify the database usually need to be annotated with `@Transactional` to ensure they run within a transaction. Looking at the stack trace, the error occurs in `XUserMgr$ExternalUserCreator.createExternalUser`, which calls `UserMgr.createUser`, which in turn uses `BaseDao.create`. The `create` method in `BaseDao` is trying to persist an entity but there's no active transaction. So maybe the `createUser` method or the code calling it isn't properly transactional. In version 2.4.0, this worked, so something must have changed in 2.5.0. Perhaps the upgrade introduced changes in how transactions are managed. Maybe a method that was previously transactional no longer is, or the transaction boundaries have shifted. Step 1: Verify Database Schema Compatibility Ranger 2.5.0 may require schema updates. Ensure the database schema is compatible with the new version: Check Upgrade Documentation: Review the Ranger 2.5.0 Release Notes for required schema changes. Example: If migrating from 2.4.0 to 2.5.0, you may need to run SQL scripts like x_portal_user_DDL.sql or apache-ranger-2.5.0-schema-upgrade.sql. Run Schema Upgrade Scripts: Locate the schema upgrade scripts in the Ranger installation directory (ranger-admin/db/mysql/patches) and apply them: mysql -u root -p ranger < apache-ranger-2.5.0-schema-upgrade.sql Validate the Schema: Confirm that the x_portal_user table exists and has the expected columns (e.g., login_id, user_role). Step 2: Check Transaction Management Configuration The error suggests a missing @Transactional annotation or misconfigured transaction manager in Ranger 2.5.0: Review Code/Configuration Changes: Compare the transaction management configurations between Ranger 2.4.0 and 2.5.0. Key files: ranger-admin/ews/webapp/WEB-INF/classes/conf/application.properties ranger-admin/ews/webapp/WEB-INF/classes/spring-beans.xml Apache Ranger JIRA: Search for issues like RANGER-XXXX related to transaction management in Ranger 2.5.0. Ensure Transactional Annotations: In Ranger 2.5.0, the method createUser in UserMgr.java or its caller must be annotated with @Transactional to ensure database operations run in a transaction. @Transactional public void createUser(...) { ... } 3. Debug Transaction Boundaries: Enable transaction logging in log4j.properties to trace transaction activity log4j.logger.org.springframework.transaction=DEBUG log4j.logger.org.springframework.orm.jpa=DEBUG Step 3: Manually Create the User (Temporary Workaround) If the user drew.nicolette is missing from x_portal_user, manually insert it into the database: INSERT INTO x_portal_user (login_id, password, user_role, status) VALUES ('drew.nicolette', 'LDAP_USER_PASSWORD_HASH_IF_APPLICABLE', 'ROLE_USER', 1); Note: This bypasses the transaction error but is not a permanent fix. Step 4: Verify LDAP Configuration Ensure LDAP settings in ranger-admin/ews/webapp/WEB-INF/classes/conf/ranger-admin-site.xml are correct for Ranger 2.5.0: <property>
<name>ranger.authentication.method</name>
<value>LDAP</value>
</property>
<property>
<name>ranger.ldap.url</name>
<value>ldap://your-ldap-server:389</value>
</property> Step 5: Check for Known Issues Apache Ranger JIRA: Search for issues like RANGER-XXXX related to transaction management in Ranger 2.5.0. 2. Apply Patches: If a patch exists (e.g., for missing @Transactional annotations), apply it to the Ranger 2.5.0 codebase. Step 6: Test with a New User Attempt to log in with a different LDAP user to see if the issue is specific to drew.nicolette or a systemic problem. If the error persists for all users, focus on transaction configuration or schema issues. If only drew.nicolette fails, check for conflicts in the x_portal_user table (e.g., duplicate entries). Final Checks Logs: Monitor ranger-admin.log and catalina.out for transaction-related errors after applying fixes. Permissions: Ensure the database user has write access to the x_portal_user table. Dependencies: Confirm that Spring and JPA library versions match Ranger 2.5.0 requirements. Happy hadooping
... View more
03-02-2025
02:31 AM
@rj27 Some clarification on the git setup This is the author name that will appear in commit messages Set the global Git username to "NiFi Registry" This is the email address associated with commits Set the global Git email to "nifi-registry@example.com" Values to be passed <flowPersistenceProvider> <property name="Flow Storage Directory">./flow_storage</property> <property name="Git Remote To Push">origin</property> <property name="Git Remote Access User">username</property> <property name="Git Remote Access Password">password</property> <property name="Remote Clone Repository">https://git-repo-url/your-flow-repo.git</property> </flowPersistenceProvider>
... View more
03-01-2025
11:46 AM
@rj27 To set up Git integration for Apache NiFi Registry using SSH authentication, you need to configure the NiFi Registry to use a Git-based flow persistence provider. Analysis of Current Setup You have Apache NiFi 1.28 running on AWS ECS Fargate You have Apache NiFi Registry 1.28 running on AWS ECS Fargate Both applications are communicating with each other successfully You need to integrate NiFi Registry with Git using SSH authentication Below are the detailed steps to achieve this on an AWS ECS instance running on Fargate with NiFi and NiFi Registry 1.28. Detailed Steps for Git Integration Step 1: Update NiFi Registry Configuration Modify the nifi-registry.properties file in your container Add the following properties to configure the Git flow persistence provider # Git Configuration nifi.registry.db.git.remote=true nifi.registry.db.git.remote.to.push=true nifi.registry.db.git.repository=/opt/nifi-registry/git-repository nifi.registry.db.git.flow.storage.directory=/opt/nifi-registry/flow-storage nifi.registry.db.git.remote.url=ssh://git@your-git-server:port/your-repo.git nifi.registry.db.git.remote.branch=master Step 2: Set Up SSH Keys for Authentication 1. Generate an SSH key pair inside your container mkdir -p /opt/nifi-registry/.ssh ssh-keygen -t rsa -b 4096 -C "nifi-registry@example.com" -f /opt/nifi-registry/.ssh/id_rsa -N "" 2. Add your public key to your Git repository's authorized keys (in GitHub, GitLab, etc.) Copy the contents of /opt/nifi-registry/.ssh/id_rsa.pub Add it to your Git provider as a deploy key or authentication key 3. Configure SSH client in the container cat > /opt/nifi-registry/.ssh/config << EOF Host your-git-server IdentityFile /opt/nifi-registry/.ssh/id_rsa StrictHostKeyChecking no UserKnownHostsFile /dev/null EOF 4. Set proper permissions chmod 700 /opt/nifi-registry/.ssh chmod 600 /opt/nifi-registry/.ssh/id_rsa chmod 644 /opt/nifi-registry/.ssh/id_rsa.pub chmod 600 /opt/nifi-registry/.ssh/config Step 3: Update ECS Task Definition for Persistence 1. Update your ECS task definition to include a volume for SSH keys and Git repository validate the JSON's "volumes": [ { "name": "nifi-registry-git", "dockerVolumeConfiguration": { "scope": "task", "driver": "local", "labels": null, "autoprovision": true } } ] 2. Mount this volume in your container definition "mountPoints": [ { "sourceVolume": "nifi-registry-git", "containerPath": "/opt/nifi-registry/.ssh", "readOnly": false }, { "sourceVolume": "nifi-registry-git", "containerPath": "/opt/nifi-registry/git-repository", "readOnly": false } ] Step 4: Configure Git User Information Set Git user configuration git config --global user.name "NiFi Registry" git config --global user.email "nifi-registry@example.com" Step 5: Initialize the Git Repository Initialize the local Git repository mkdir -p /opt/nifi-registry/git-repository cd /opt/nifi-registry/git-repository git init git remote add origin ssh://git@your-git-server:port/your-repository.git 2. Test the connection ssh -T git@your-git-server Step 6: Configure NiFi to Connect to NiFi Registry In NiFi UI, configure the Registry Client: Click on the hamburger menu (≡) in the top-right corner Select "Controller Settings" Go to the "Registry Clients" tab Add a new Registry Client with: Name: Git-Backed Registry URL: http://your-nifi-registry:18080 Step 7: Restart NiFi Registry Restart the NiFi Registry service to apply change # If using systemd systemctl restart nifi-registry # If using the command line ./bin/nifi-registry.sh restart # In AWS ECS, update the service to force new deployment aws ecs update-service --cluster your-cluster --service your-nifi-registry-service --force-new-deployment Troubleshooting 1. Check NiFi Registry logs for Git-related errors: tail -f /opt/nifi-registry/logs/nifi-registry-app.log 2. Verify SSH connectivity ssh -vT git@your-git-server 3. Common issues: Permission problems: Ensure the NiFi Registry user has appropriate permissions Known hosts: If StrictHostKeyChecking is on, you need to accept the host key first Firewall: Ensure outbound connections to the Git server are allowed from the ECS task Important precautions Security: Ensure the private key is stored securely and not exposed in the container image or logs. Automation: Consider using AWS Secrets Manager or Parameter Store to manage the SSH key and passphrase securely. Backup: Regularly back up your Git repository to avoid data loss. Happy hadooping
... View more
02-12-2025
01:42 AM
@0tto Please could you share your NiFi logs. Happy hadooping
... View more
01-27-2025
01:18 AM
@ose_gold The SFTP issues appear to stem from incorrect permissions and ownership in your Docker setup. Here's the analysis and solution: Key Issues: Root ownership instead of user 'foo' for /home/foo Incorrect chroot directory permissions Docker volume mount permissions You have a volume nifi-conf:/opt/nifi/nifi-current/conf for the NiFi container, but it's not declared in the volumes section at the bottom check the addition below Docker Compose has newer versions 3.8 It might be a good idea to update to a more recent version depending on the features you need. version: '3' #Docker Compose has newer versions 3.8
services:
nifi:
image: apache/nifi:latest # Consider specifying a version
container_name: nifi
ports:
- "8089:8443"
- "5656:5656"
volumes:
- nifi-conf:/opt/nifi/nifi-current/conf
environment:
NIFI_WEB_PROXY_HOST: localhost:8089
SINGLE_USER_CREDENTIALS_USERNAME: admin
SINGLE_USER_CREDENTIALS_PASSWORD: {xxyourpasswdxx}
sftp:
image: atmoz/sftp
volumes:
- ./sftp/upload:/home/foo/upload
ports:
- "2222:22"
command: foo:pass:1001
# Add these permissions
user: "1001:1001"
environment:
- CHOWN_USERS=foo
- CHOWN_DIRS=/home/foo
volumes:
nifi-conf: Before starting containers # Set correct permissions on host
mkdir -p ./sftp/upload
chown -R 1001:1001 ./sftp/upload
chmod 755 ./sftp/upload This configuration: Sets proper user/group ownership Maintains correct chroot permissions Ensures volume mount permissions are preserved Prevents permission conflicts between host and container Happy Hadooping
... View more
01-20-2025
05:41 AM
@rsurti If SAML authentication works for LAN users but not for users on Wi-Fi, even when both are on the same network, it suggests differences in how the network or devices are configured for each connection type. Here’s how you can troubleshoot and resolve this issue: DNS Resolution: Check if Wi-Fi users can resolve the identity provider (IdP) and service provider (SP) URLs correctly. nslookup idp.example.com Capture SAML requests/responses using browser developer tools (Network tab). Look for differences in: Redirect URLs Assertions Error codes Common issues include: Misconfigured callback URLs. Device Configuration Check if device firewalls or VPNs are interfering with SAML traffic over Wi-Fi. Ensure browser settings (e.g., cookie policies) do not block SAML cookies. Connect a user to LAN and Wi-Fi simultaneously (if possible) to identify differences in routing or access. Please revert Happy hadooping
... View more