There are no available Samebug tips for this exception. Do you have an idea how to solve this issue? A short tip would help users who saw this issue last week.

  • This might not be a bug. Here is the description. Any workarounds are appreciated. I am only able to execute hadoop commands using principals which are in the default realm. seems to be ignored. Attached is a log of everything done. Here is overview of the configuration and some troubleshooting tests: # created and tested a principal using the KDC instead of AD and confirmed all OK hadoop george@EC2.INTERNAL Name: george@EC2.INTERNAL to george # fails to use with principal from AD, seems to ignore rules in hadoop george@CLOUDSECURE.LOCAL Exception in thread "main"$NoMatchingRule: No rules applied to george@CLOUDSECURE.LOCAL at at # note: ip-10-151-51-135.ec2.internal has Win 2008 R2 + AD DS with 1 forest, and defines all user accounts used for authentication /etc/krb5.conf [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = EC2.INTERNAL dns_lookup_realm = false dns_lookup_kdc = false max_life = 1d max_renewable_life = 7d ticket_lifetime = 24h renew_lifetime = 7d forwardable = true default_tgs_enctypes = aes256-cts aes128-cts arcfour-hmac des3-hmac-sha1 des-hmac-sha1 des-cbc-md5 des-cbc-crc default_tkt_enctypes = aes256-cts aes128-cts arcfour-hmac des3-hmac-sha1 des-hmac-sha1 des-cbc-md5 des-cbc-crc [realms] EC2.INTERNAL = { kdc = ip-10-191-70-81.ec2.internal admin_server = ip-10-191-70-81.ec2.internal default_domain = EC2.INTERNAL } CLOUDSECURE.LOCAL = { kdc = ip-10-151-51-135.ec2.internal:88 admin_server = ip-10-151-51-135.ec2.internal:749 default_domain = EC2.INTERNAL } [domain_realm] .ec2.internal = EC2.INTERNAL ec2.internal = EC2.INTERNAL cat /etc/hadoop/conf.cloudera.hdfs1/core-site.xml <?xml version="1.0" encoding="UTF-8"?> <!--Autogenerated by Cloudera CM on 2013-10-06T10:16:50.792Z--> <configuration> <property> <name>fs.defaultFS</name> <value>hdfs://ip-10-191-70-81.ec2.internal:8020</value> </property> <property> <name>fs.trash.interval</name> <value>1</value> </property> <property> <name></name> <value>kerberos</value> </property> <property> <name></name> <value>authentication</value> </property> <property> <name></name> <value>RULE:[1:$1@$0](.*@\QEC2.INTERNAL\E$)s/@\QEC2.INTERNAL\E$// RULE:[2:$1@$0](.*@\QEC2.INTERNAL\E$)s/@\QEC2.INTERNAL\E$// RULE:[1:$1@$0](.*@\QCLOUDSECURE.LOCAL\E$)s/@\QCLOUDSECURE.LOCAL\E$// RULE:[2:$1@$0](.*@\QCLOUDSECURE.LOCAL\E$)s/@\QCLOUDSECURE.LOCAL\E$// DEFAULT</value> </property> </configuration>
    via by Daniel Rule,
  • Here's what I'm observing on a fully distributed cluster deployed via Bigtop from the RC0 2.0.3-alpha tarball: {noformat} 528077-oozie-tucu-W@mr-node] Error starting action [mr-node]. ErrorType [TRANSIENT], ErrorCode [JA009], Message [JA009:$NoMatchingRule: No rules applied to yarn/localhost@LOCALREALM at<init>( at org.apache.hadoop.mapreduce.v2.api.MRDelegationTokenIdentifier.<init>( at org.apache.hadoop.mapreduce.v2.hs.HistoryClientService$HSClientProtocolHandler.getDelegationToken( at org.apache.hadoop.mapreduce.v2.api.impl.pb.service.MRClientProtocolPBServiceImpl.getDelegationToken( at org.apache.hadoop.yarn.proto.MRClientProtocol$MRClientProtocolService$2.callBlockingMethod( at org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ at org.apache.hadoop.ipc.RPC$ at org.apache.hadoop.ipc.Server$Handler$ at org.apache.hadoop.ipc.Server$Handler$ at Method) at at at org.apache.hadoop.ipc.Server$ Caused by:$NoMatchingRule: No rules applied to yarn/localhost@LOCALREALM at at<init>( ... 12 more ] {noformat} This is submitting a mapreduce job via Oozie 3.3.1. The reason I think this is a Hadoop issue rather than the oozie one is because when I hack /etc/krb5.conf to be: {noformat} [libdefaults] ticket_lifetime = 600 default_realm = LOCALHOST default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc [realms] LOCALHOST = { kdc = localhost:88 default_domain = .local } [domain_realm] .local = LOCALHOST [logging] kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmin.log default = FILE:/var/log/krb5lib.log {noformat} The issue goes away. Now, once again -- the kerberos auth is NOT configured for Hadoop, hence it should NOT pay attention to /etc/krb5.conf to begin with.
    via by Roman Shaposhnik,
  • SOLR security configured accordingly [this document|] User from primary realm (used by Hadoop cluster itself) can access the console, but user from trusted realm can't. {code} Sep 24, 2014 9:30:13 AM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet LoadAdminUI threw exception$NoMatchingRule: No rules applied to admin@TRUSTED.REALM at at$ at$ at Method) at at at at org.apache.solr.servlet.SolrHadoopAuthenticationFilter.doFilter( at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter( at org.apache.catalina.core.ApplicationFilterChain.doFilter( at org.apache.solr.servlet.HostnameFilter.doFilter( at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter( at org.apache.catalina.core.ApplicationFilterChain.doFilter( at org.apache.catalina.core.StandardWrapperValve.invoke( at org.apache.catalina.core.StandardContextValve.invoke( at org.apache.catalina.core.StandardHostValve.invoke( at org.apache.catalina.valves.ErrorReportValve.invoke( at org.apache.catalina.core.StandardEngineValve.invoke( at org.apache.catalina.connector.CoyoteAdapter.service( at org.apache.coyote.http11.Http11Processor.process( at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process( at$ at {code} Required kerberos auth_to_local rules are defined in hadoop/core-site.xml file and was added to /etc/krb5.conf as well. Another CDH components (for example, Impala) use these rules and allow access for users from trusted domain.
    via by Andrejs Dubovskis,
    • failure to login at at at org.apache.hadoop.fs.FileSystem$Cache$Key.<init>( at org.apache.hadoop.fs.FileSystem$Cache$Key.<init>( at org.apache.hadoop.fs.FileSystem$Cache.get( at org.apache.hadoop.fs.FileSystem.get( at org.apache.hadoop.fs.FileSystem.get( at visa.poc_01_serialwriteseq_kerberos_0_1.POC_01_SerialWriteSEQ_Kerberos.tFileInputDelimited_1Process( at visa.poc_01_serialwriteseq_kerberos_0_1.POC_01_SerialWriteSEQ_Kerberos.tLibraryLoad_1Process( at visa.poc_01_serialwriteseq_kerberos_0_1.POC_01_SerialWriteSEQ_Kerberos.runJobInTOS( at visa.poc_01_serialwriteseq_kerberos_0_1.POC_01_SerialWriteSEQ_Kerberos.main( Caused by: java.lang.IllegalArgumentException: Illegal principal name svchdc6p@VISA.COM at<init>( at<init>( at$HadoopLoginModule.commit( at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( at sun.reflect.DelegatingMethodAccessorImpl.invoke( at java.lang.reflect.Method.invoke( at at$000( at$ at$ at Method) at at at ... 10 more Caused by:$NoMatchingRule: No rules applied to user@FOOBAR.COM at at<init>( ... 24 more

    Users with the same issue

    Unknown visitor1 times, last one,