Member since
08-20-2018
13
Posts
5
Kudos Received
1
Solution
My Accepted Solutions
Title | Views | Posted |
---|---|---|
1569 | 11-27-2018 02:55 PM |
02-08-2019
07:10 AM
We need to use the proxy and SSO service with IBM WebSEAL which we are using in our enterprise level. To use this service we need to feed the following string in our http header for all webUI's <% String ivuser = request.getHeader("iv-user"); %> As per the latest code. It is not possible to add custom headers. Is there any way we can add the custom http headers to configure our SSO integration. https://github.com/apache/ambari/blob/cbd628460a186991f8cf2c391657eb5891c2ab82/ambari-server/src/main/java/org/apache/ambari/server/security/AbstractSecurityHeaderFilter.java#L186
... View more
Labels:
02-04-2019
07:08 AM
2 Kudos
This article related to the creating SNMP alert through custom script and How to troubleshoot. 1- Install SNMP on sandbox or local environment. yum install net-snmp net-snmp-utils net-snmp-libs –y 2- Change the script /etc/snmp/snmptrapd.conf file and include "disableAuthorization yes" # Example configuration file for snmptrapd
#
# No traps are handled by default, you must edit this file!
#
# authCommunity log,execute,net public
# traphandle SNMPv2-MIB::coldStart /usr/bin/bin/my_great_script cold
disableAuthorization yes
To understand why this change required, Refer the Access Control section of the provided link. -- http://www.net-snmp.org/docs/man/snmptrapd.conf.html
3- Copy APACHE-AMBARI-MIB.txt file to /usr/share/snmp/mibs folder. cp /var/lib/ambari-server/resources/APACHE-AMBARI-MIB.txt /usr/share/snmp/mibs *Make Sure it has proper Permission* 4- Startup a simple SNMP trap daemon to log traps to the /tmp/traps.log file for testing purposes. nohup snmptrapd -m ALL -A -n -Lf /tmp/traps.log & 5- Invoke a test trap to ensure that the snmptrapd is logging appropriately to /tmp/traps.log and the Apache Ambari MIB is being respected. snmptrap -v 2c -c public localhost '' APACHE-AMBARI-MIB::apacheAmbariAlert alertDefinitionName s "definitionName" alertDefinitionHash s "definitionHash" alertName s "name" alertText s "text" alertState i 0 alertHost s "host" alertService s "service" alertComponent s "component"
6- You should be able to see the below traps in /tmp/traps.log. 2019-02-04 06:24:38 UDP: [127.0.0.1]:59238->[127.0.0.1]:162 [UDP: [127.0.0.1]:59238->[127.0.0.1]:162]:
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (224395199) 25 days, 23:19:11.99SNMPv2-MIB::snmpTrapOID.0 = OID: APACHE-AMBARI-MIB::apacheAmbariAlertAPACHE-AMBARI-MIB::alertDefinitionName = STRING: "definitionName"APACHE-AMBARI-MIB::alertDefinitionHash = STRING: "definitionHash"APACHE-AMBARI-MIB::alertName = STRING: "name"APACHE-AMBARI-MIB::alertText = STRING: "text"APACHE-AMBARI-MIB::alertState = INTEGER: ok(0)APACHE-AMBARI-MIB::alertHost = STRING: "host"APACHE-AMBARI-MIB::alertService = STRING: "service"APACHE-AMBARI-MIB::alertComponent = STRING: "component" 7- Now we will be creating the script which will be used by Ambari for sending SNMP traps.
Create a file that contains the script, named /tmp/snmp_mib_script.sh, in this example. It's recommended to create this file in a more permanent directory for actual use. Format of the Alert Script-- #!/bin/bash
HOST=localhost
COMMUNITY=public
STATE=0
if [[ $4 == "OK" ]]; then
STATE=0
elif [[ $4 == "UNKNOWN" ]]; then
STATE=1
elif [[ $4 == "WARNING" ]]; then
STATE=2
elif [[ $4 == "CRITICAL" ]]; then
STATE=3
fi
/usr/bin/snmptrap -v 2c \
-c $COMMUNITY $HOST '' APACHE-AMBARI-MIB::apacheAmbariAlert \
alertDefinitionId i 0 \
alertDefinitionName s "$1" \
alertDefinitionHash s "n/a" \
alertName s "$2" \
alertText s "$5" \
alertState i $STATE \
alertHost s `hostname` \
alertService s "$3" \
alertComponent s
Note-- Make Sure to change the Host with the desired sandbox or host where you want to send the traps.
Reference-- http://mail-archives.apache.org/mod_mbox/ambari-commits/201510.mbox/%3C2cdb030d3ef64fffb2540097f885f3eb@git.apache.org%3E 8- Add the following line to the /etc/ambari-server/conf/ambari.properties file org.apache.ambari.contrib.snmp.script=/tmp/snmp_mib_script.sh 9- Restart the Ambari-server. 10- Now we will use the below api call to add an alert target for the script. curl -u "admin_user":"admin_password" -H 'X-Requested-By: ambari' http://<Ambari_host>:<PORT>/api/v1/alert_targets -d '{ "AlertTarget" : { "name" : "SNMP_MIB", "description" : "SNMP MIB Target", "notification_type" : "ALERT_SCRIPT","global": true,"properties": {"ambari.dispatch-property.script": "org.apache.ambari.contrib.snmp.script"}}}]}' If you want to update the alert_states as critical only, you can add below lines in script. {
"AlertTarget": {
"alert_states": ["CRITICAL"]
}
} 11- You can check the Alert notification that has been created in Ambari UI.
Note-- Check any snmptrapd process is currently running. If so, Cancel that process. Example-- # ps -ef|grep snmptrapd
root 15286 15087 0 06:49 pts/0 00:00:00 grep --color=auto snmptrapd
root 21610 1 0 Jan24 ? 00:00:59 snmptrapd -m ALL -A -n -Lf /tmp/traps.log
#kill -9 21610 TroubleShooting---
1- Whenever any alert will be triggered you will be able to see below lines in Ambari-server.log. INFO [AlertNoticeDispatchService RUNNING] AlertNoticeDispatchService:279 - There are xx pending alert notices about to be dispatched... This means Ambari is successfully sending the SNMP traps to the mentioned host. 2- At the same-time stamp you can check the entry in ambari-alert.log file.
3- For any change in alert state, there will be a entry which will get recorded in alert_notice table in database. If there is no entry available then
check the notification set in alert_target table. Hope this article will help!!!!! Reference--
https://github.com/apache/ambari/tree/trunk/contrib/alert-snmp-mib
... View more
- Find more articles tagged with:
- Ambari
- ambari-agent
- ambari-alerts
- ambari-server
- How-ToTutorial
- Sandbox & Learning
- snmp
- snmptrap
Labels:
12-10-2018
07:00 AM
3 Kudos
When an ambari agent starts, it bootstraps with the ambari server via registration. The server sends information to the agent about the components that have been enabled for auto start along with the other auto start properties in ambari.properties. The agent compares the current state of these components against the desired state, to determine if these components are to be installed, started, restarted or stopped. These are the values ambari-server will send to ambari-agent by default unless configured in cluster-env.xml file. "recovery_max_count": "6", "recovery_lifetime_max_count": "1024", "recovery_type": "AUTO_START", "recovery_window_in_minutes": "60", recovery_lifetime_max_count ---- The maximum number of recovery attempts of a failed component during the lifetime of an Ambari Agent instance. This is reset when the Ambari Agent is restarted. recovery_window_in_minutes -- The length of a recovery window, in minutes, in which recovery attempts can be retried. recovery_max_count --- The maximum number of recovery attempts of a failed component during a specified recovery window. recovery_type ---- The type of automatic recovery of failed services and components to use. The following are examples of valid values for recovery_type Attribute: recovery_type Commands State Transitions AUTO_START Start INSTALLED → STARTED FULL Install, Start, Restart, Stop INIT → INSTALLED, INIT → STARTED, INSTALLED → STARTED, STARTED → STARTED, STARTED → INSTALLED DEFAULT None Auto start feature disabled For Example:-- If you want your host component not to auto start whenever your VM crashes and reboots then you have to change the "recovery_type": "AUTO_START" to "recovery_type": "DEFAULT"(Auto start feature disabled). Similarly if you want to decrease the number of recovery attempt of any failed component, Then you have to change the value of recovery_max_count accordingly. Hope this article will help!!!!! Reference:-- https://cwiki.apache.org/confluence/display/AMBARI/Recovery%3A+auto+start+components
... View more
- Find more articles tagged with:
- ambari-agent
- ambari-server
- ambari-service
- configuration
- How-ToTutorial
- Sandbox & Learning
Labels:
11-30-2018
02:16 PM
@Rajeev, Kindly accept my answer if it fulfill your query. Ambari Server depends on the FQDN of the hosts (Setting IP Addresses are not good idea). Most of the configurations requires that we pass either 0.0.0.0 address (listen to all available network interfaces) OR listen to FQDN (hostname -f). So if your configurations should be having mostly the FQDNs (like "zookeeper.connect" , "listeners" ...etc) should be using the FQDN then changing the IP Address will not have any effect. Only you will need to make the required DNS mapping changes or the "/etc/hosts" file changes. So you can stop the services that that gets affected due to IP Address change and then make the IP Address change (either at DNS level OR in the "/etc/hosts" file) and then restart the services. (Assuming that you have not hardcoded any IP Address in the kafka or other component configurations). Also we will need to restart the ambari agents on those hosts. https://community.hortonworks.com/content/supportkb/48998/correct-procedure-to-re-ip-a-client-host-in-a-clus.html
... View more
11-29-2018
01:00 PM
@Krishna Venkata To access the NIFI through SSL you need to load the user certificate in your browser. Then you will be able to access the NIFI UI. To understand the procedure to do the same. Kindly follow the link below. https://www.batchiq.com/nifi-configuring-ssl-auth.html If it resolve your query. Kindly accept my answer. Hope it helps!!!!!!!!
... View more
11-28-2018
05:30 AM
@Kei Miyauchi, Great it worked!!!! Kindly accept my previous answer. Regarding your query, Which all components you are using to authenticate via knox.
... View more
11-27-2018
02:55 PM
@Kei Miyauchi, Do you see any error like this in your ambari-server logs and ambari-agent logs. 30 Oct 2018 17:12:14,908 WARN [ambari-client-thread-8243] JwtAuthenticationFilter:381 - JWT expiration date validation failed. 30 Oct 2018 17:12:14,910 WARN [ambari-client-thread-8243] JwtAuthenticationFilter:173 - JWT authentication failed - Invalid JWT token 30 Oct 2018 17:12:19,922 WARN [ambari-client-thread-8243] JwtAuthenticationFilter:381 - JWT expiration date validation failed. 30 Oct 2018 17:12:19,922 WARN [ambari-client-thread-8243] JwtAuthenticationFilter:173 - JWT authentication failed - Invalid JWT token. If this is the case then you should check the knosso.token.ttl property. This you can find in Ambari > Knox > Configs > Advanced knoxsso-topology. knosso.token.ttl should be 30 seconds by default. checkout the below kb article. https://community.hortonworks.com/content/supportkb/223278/errorjwt-authentication-failed-invalid-jwt-token-w.html and if this is not the issue then can you please upload the ambari-sever logs ambari-audit logs. Hope this helps!!!!!!!!
... View more
11-27-2018
05:52 AM
You can check the HDP version from Ambari UI. for 2.7 and Higher Version : Stack and Versions->Versions for 2.6 or Lower Version : Admin->Stack and Versions->Versions From Command Line try these commands to check the HDP version. hdp-select rpm -qa|grep hadoop
... View more