Terminal hack to make logging into a cluster easier

I’ve been looking for a way to make it simpler to quickly login to all nodes of a cluster from a mac terminal. Discovered a small npm module that helped me do it called ttab. With this npm module I can then write a bash script:



rs6 () {
ttab -w ssh bryan@example1.com
ttab ssh bryan@example2.com
ttab ssh bryan@example3.com
ttab ssh bryan@example4.com
ttab ssh bryan@example5.com
ttab ssh bryan@example6.com

if [ “rs6” = $TYPE ]

This will open one new terminal window with 6 tabs all logged into the different servers.

Spring Boot with JSP and React Template Application

Awhile back I was playing around with moving some personal applications to use spring boot. There are a lot of really nice aspects to this project. You get a whole lot of functionality without having to write boilerplate code.

  1. Executable jar file.
    1. packages entire application as a single executable file.
  2. Service Support
    1. link to your executable jar from /etc/init.d and you get full Linux service support (start, stop, restart, status)
    2. logs go to /var/log/{application name}.log
    3. PID status support in /var/run/
  3. Embedded web container
    1. tomcat or jetty is upgraded with your spring boot version, so you don’t have a separate set of binaries to maintain.

The biggest downside that I could see was that JSPs are not supported out of the box because of a tomcat issue. Spring boot is perfect for developing REST microservices but somewhat limited as a general purpose web application replacement. You need to convert your display code to use Thymeleaf templates, which could be a significant amount of work.

I came across a workaround to get JSPs working as expected. It involved moving files out of the /WEB-INF/ directory and putting them in /resources/META-INF/resources/WEB-INF/. It’s a little weird, but when you do it, everything works as expected. You’re even able to use things like JSP tags just as you would have before.

Another thing that I’ve been spending time thinking about is how to integrate a Java development project with a current Javascript setup. Maven works as well as anything for a large multi-module structure, but how does the Javascript code incorporate? There are a lot of different options. I wanted a build pipeline that would allow you to use the more popular Javascript tools, not break for non-Javascript developers, and allow fast iteration of Javascript changes (doesn’t require a full ‘mvn clean package’ to see changes).

After all of this experimentation, I believe I’ve found a good balance of tools for both Java and Javascript developers. It uses Spring Boot with full JSP support as a base. Gulp and Webpack for the Javascript build pipeline. Has a development mode that uses the Webpack dev server to iterate quickly. It also includes support for development with React, so you can play with the cutting edge of developing web applications.

I’ve done all of the fiddlings with different settings and created a working template application.  Check it out and let me know what you think.

Changing Kerberos Expiration To Test Ticket Renewal

If you’re testing a Kerberos enabled hadoop cluster and want to make sure that ticket renewal is working as expected, you’ll probably want to change the ticket renewal time so that you don’t have to wait 24 hours for each test.

Using a “krb5-server” as an authentication source for a Hadoop Cluster. You can run the following commands to change the default ticket lifespan. 

kadmin.local: getprinc krbtgt/EXAMPLE.COM@EXAMPLE.COM

Expiration date: [never]
Last password change: [never]
Password expiration date: [none]
Maximum ticket life: 1 days 00:00:00
Maximum renewable life: 365 days 00:00:00
Last modified: Wed Nov 19 00:09:37 UTC 2014 (quick/admin@EXAMPLE.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 7
Key: vno 1, aes256-cts-hmac-sha1-96, no salt
Key: vno 1, aes128-cts-hmac-sha1-96, no salt
Key: vno 1, des3-cbc-sha1, no salt
Key: vno 1, arcfour-hmac, no salt
Key: vno 1, des-hmac-sha1, no salt
Key: vno 1, des-cbc-md5, no salt
Key: vno 1, des-cbc-crc, no salt
MKey: vno 1
Policy: [none]

To change the default ticket expiration from 1 day to 30 minutes, issue the following command:

kadmin.local:  modprinc -maxlife “30 minutes” krbtgt/EXAMPLE.COM@EXAMPLE.COM

You should then be able to verify that the settings have taken effect:

[root@host ~]# kinit -k -t hdfs.keytab hdfs
[root@host ~]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: hdfs@EXAMPLE.COM
Valid starting     Expires            Service principal
08/22/16 20:24:18  08/22/16 20:54:18  krbtgt/EXAMPLE.COM@EXAMPLE.COM
renew until 08/29/16 20:24:18

You should see that the “Expires” time is 30 minutes in the future. This keytab will be renewed every 30 minutes for 7 days.

The interesting point that isn’t well documented is that there is a hierarchy to the settings in Kerberos. You can modify each individual principle’s maxlife and maxrenewlife, but if a higher level principle has stricter settings then they will be used. The krbtgt principle is the top level principle. Changes made here will apply to all other principles.