Blog Entries tagged java
Feeds: RSS | Atom

Zookeeper + Kerberos Ticket Cache

Published: 2015-04-30 09:49 UTC. Tags: java kerberos

Was trying to connect to zookeeper with kerberos authentication. This was giving me the following "helpful" error message:

WARN
[main-SendThread(zookeeper.example.com:2181):ZooKeeperSaslClient$ClientCallbackHandler@459] -
Could not login: the client is being asked for a password, but the Zookeeper client code does
not currently support obtaining a password from the user. Make sure that the client is
configured to use a ticket cache (using the JAAS configuration setting 'useTicketCache=true)'
and restart the client. If you still get this message after that, the TGT in the ticket cache
has expired and must be manually refreshed. To do so, first determine if you are using a
password or a keytab. If the former, run kinit in a Unix shell in the environment of the
user who is running this Zookeeper client using the command 'kinit <princ>'
(where <princ> is the name of the client's Kerberos principal). If the latter,
do 'kinit -k -t <keytab> <princ>' (where <princ> is the name of the Kerberos principal,
and <keytab> is the location of the keytab file). After manually refreshing your cache,
restart this client. If you continue to see this message after manually refreshing your cache,
ensure that your KDC host's clock is in sync with this host's clock.

[Krb5LoginModule] authentication failed

I was using the following command line:

CLIENT_JVMFLAGS="-Djava.security.auth.login.config=/home/forsberg/jaas.conf" zookeeper-client -server zookeeper.example.com:2181

With jaas.conf containing:

Client {
   com.sun.security.auth.module.Krb5LoginModule required
   useTicketCache=true;
};
Not a very helpful error message. Adding -Dsun.security.krb5.debug=true to the cmdline gave more information::
unsupported key type found the default TGT: 18

This combined with https://unix.stackexchange.com/questions/23012/java-could-not-get-the-tgt-from-cache-in-linux-client/23172 made me realize I had forgotten to install the "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files" on this particular machine.

Problem solved.

0 comments.

Java SIGBUS - an unclear way of saying /tmp is full

Published: 2011-05-02 19:27 UTC. Tags: linux java

I had the following happen for every new java process on one of my servers the other day:

server:~$ java
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGBUS (0x7) at pc=0x00007f3e0c5aad9b, pid=17280, tid=139904457242368
#
# JRE version: 6.0_24-b07
# Java VM: Java HotSpot(TM) 64-Bit Server VM (19.1-b02 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  [libc.so.6+0x7ed9b]  memset+0xa5b
#
# An error report file with more information is saved as:
# /home/user/hs_err_pid17280.log
Segmentation fault

Turns out this is Java's way of telling you that the /tmp directory is full. It's trying to mmap some performance/hotspot-related file in /tmp which succeeds, but when it's trying to access this area, it will get the SIGBUS signal.

More info here

0 comments.