Agile Orbit

Unlimited Strength Crypto in Java 8u151+

Thu, 26 Oct 2017 00:00:00 +0000

Oracle Java Development Kit (JDK) 8u151 & 8u152+ now allows you to set a “crypto.policy Security property in the java.security file” instead of separately downloading & installing the JCE extensions (which everyone seems to struggle with the first time, deployment issues, etc).

It’s much easier now. Here’s how you can do it per JVM (remember this is only on 8u151+)

# Name or location of file can be anything:
$ echo crypto.policy=unlimited > ~/.unlimited.security.properties
$ JAVA_OPTS=-Djava.security.properties=~/.unlimited.security.properties
$ groovysh
groovy:000> println(javax.crypto.Cipher.getMaxAllowedKeyLength("AES"))
2147483647

Or system wide:

edit $JAVA_HOME/jre/lib/security/java.security

Uncomment

-#crypto.policy=unlimited
+crypto.policy=unlimited

One downside of this approach though is that you will have to remember to do this each time you update your JDK.

JDK 8u152 release notes - http://www.oracle.com/technetwork/java/javase/8u152-relnotes-3850503.html#JDK-8157561

Introducing the Grails Schwartz Plugin

Mon, 11 Jul 2016 00:00:00 +0000

We are excited to share the release of a new Grails plugin called Schwartz! This new plugin has been in the works for awhile at Agile Orbit and we are excited to finally release it! The plugin is released under the Apache 2.0 open-source license.

Source: https://github.com/agileorbit/grails-schwartz
Documentation: http://blog.agileorbit.com/grails-schwartz/
Bintray https://bintray.com/agileorbit/grails-plugins/schwartz

The Schwartz plugin integrates the Quartz Enterprise Job Scheduler with Grails, making it easy to schedule and manage recurring and ad-hoc jobs for asynchronous and synchronous processing. The plugin is similar at a high level to the existing Quartz plugin. The two plugins are similar in many ways, but significantly different in others. There are lots of details about the differences in the extensive plugin documentation.

The documentation also has tutorials for creating jobs, setting up JDBC tables and clustering.

We think the Schwartz plugin is a great alternative to the current Quartz plugin! Hopefully you will too! We look forward to hearing your feedback on Schwartz!

Using http/2 with Grails 3

Fri, 22 Apr 2016 00:00:00 +0000

Grails 3 uses Tomcat 8 by default, but thanks to Spring Boot it’s easy to change out the underling servlet container to another container such as Undertow or Jetty. One reason to do this would be if you want to take advantage of the different runtime characteristics of Undertow such as http/2 (multiplexing)[0], lightweight memory footprint, and async io (xnio)[1].

In this quick demo, we’ll show how to switch a Grails 3 app to use Undertow and configure it to use the new http/2 standard.

Configuration:

First, lets comment out Tomcat in favor of Undertow build.gradle:

dependencies {
    // compile "org.springframework.boot:spring-boot-starter-tomcat"
    compile "org.springframework.boot:spring-boot-starter-undertow"
}

Next we have to customize the embeddedServletContainerFactory bean to setup HTTP/2.

Add this method to your grails-app/init/<pkg>/Application.groovy:

@Bean
UndertowEmbeddedServletContainerFactory embeddedServletContainerFactory(){
    UndertowEmbeddedServletContainerFactory factory=new UndertowEmbeddedServletContainerFactory();

    factory.addBuilderCustomizers(new UndertowBuilderCustomizer(){
        @Override public void customize(Undertow.Builder builder){
            builder.setBufferSize(1024 * 32)
                    .setIoThreads(Runtime.getRuntime().availableProcessors() * 2)
                    .setServerOption(UndertowOptions.ENABLE_HTTP2, true)
                    .setWorkerThreads(64)
                    // There are many more options, see the documentation for more.
        }
    });
    return factory;
}

TLS

http/2 does not require a TLS connection per the spec, but Undertow only enables http/2 if the connection is secure. This means we’ll need to setup a private key and certificate.

Create and set a keystore

Create a self signed key

keytool -genkey -keyalg RSA -alias selfsigned -keystore keystore.jks -storepass password -validity 360 -keysize 2048

In grails-app/config/application.yml set the keystore, port and secrets

server:
    port: 8443
    ssl:
      key-store: /path/to/keystore.jks
      key-store-password: changeit
      key-password: password

Get ALPN

ALPN stands for Application Layer Protocol Negotiation, and is a TLS extension that allows a client to negotiate the next protocol to use after the TLS handshake is complete.

ALPN is currently not included in Java 8. So we’ll have to download it and include it in our Java command options when running with http/2:

IMPORTANT: The version of ALPN is specific to the JDK version you are using. You can find the version for your specific JDK version here: https://eclipse.org/jetty/documentation/current/alpn-chapter.html

# When running the app include this in your `-Xbootclasspath/p:`
wget http://central.maven.org/maven2/org/mortbay/jetty/alpn/alpn-boot/8.1.6.v20151105/alpn-boot-8.1.6.v20151105.jar

Running

To pass the -Xbootclasspath/p options to Gradle we’ll need to add this at to our bootRun task in build.gradle:

bootRun {
    systemProperties = System.properties
}

# Running in Dev
./gradlew bootRun -Xbootclasspath/p:build/libs/alpn-boot-8.1.6.v20151105.jar

# Running as standalone jar
./gradlew assemble
cd build/libs

# Remember to include the alpn lib
java -Xbootclasspath/p:alpn-boot-8.1.6.v20151105.jar -jar myapp.war

You can see the Protocol Version is listed as HTTP/2.0

Conclusion

It’s easy to change the container a Grails 3 app is running in to fit your workload. Tomcat, Undertow, and Jetty are all available from Spring Boot to use in Grails 3.

Notes

Tested on JDK 8u66, Grails 3.1.5
[0] - https://http2.github.io/faq/
[1] - http://undertow.io/
http://undertow.io/blog/2015/04/27/An-in-depth-overview-of-HTTP2.html
https://github.com/making/demo-http2

Publishing Grails 3 Plugins

Wed, 07 Oct 2015 00:00:00 +0000

Grails 3 plugins are distributed through Bintray. This is great because it provides everyone the ability to easily publish their own plugins. Bintray is a generic distribution platform and might be a bit overwhelming at first, but it’s a great platform for distribution and it’s also quickly becoming the new de-facto standard for Jars as opposed to Maven Central. There are a couple items that newcomers might get stuck on though when publishing their first Grails 3 plugin and this post will hopefully help those users get started.

If you don’t have a Bintray account, go create one! It’s free and really easy. Also, if you haven’t read this blog post, please read it and come back when done. It provides a good introduction.

Now that you have an account and maybe have published a simple plugin, it’s time to hopefully answer a few questions you might have encountered!

1) Where is the Group ID on the Bintray artifact page?

Maven artifacts are represented as groupId:artifactId:version. The artifactId and version are easy to find in Bintray, but not the groupId. To find the groupId, you have to go to the file, and click on (i) icon to see the maven/gradle dependency snippet. By default, all Grails plugins use the groupId of org.grails.plugins, but you can certainly change this if you’d like. There is no hard requirement to use this groupId for your plugin. The groupId is set in build.gradle like this: group 'org.grails.plugins'

2) I see some Grails plugins named “org.grails.plugins:something” and some named just “something”. What is the correct Bintray package naming standard for a Grails plugin?

Name it just the short name or the equivalent of the artifactId (something). Do not put org.grails.plugins or any other groupId in the Bintray package name. The convention of groupId:artifactId is from when Maven artifacts were migrated to Bintray and should not be used for new packages. Your Maven repository artifacts in Bintray still have a groupId regardless of what you name the package. I updated the sample publishing artifacts (more details below in #6) to accommodate this recommendation in this commit.

3) How do I find the actual project for a Bintray package?

I don’t have a good answer for this question, but rather what I will say is that given Bintray is a completely separate binary management system from Grails, we as a community need to be a little more diligent about ensuring we have correct meta-data for our plugins so community members don’t have to dig for information. For instance, always provide these data elements in gradle.settings for your plugin:

websiteUrl = 'https://somebody.github.io/grails-something'
issueTrackerUrl = 'https://github.com/somebody/grails-something/issues'
vcsUrl = 'https://github.com/somebody/grails-something'

I’m recommending the GitHub Pages URL for a repo (the gh-pages branch) to always be the website for your plugin since there is no longer a “Grails plugin portal page” for Grails 3 plugins. I would recommend using AsciiDoc to build any new documentation as opposed to the Grails documentation engine. You can see a good example of AsciiDoc being used for plugin documentation here. These URLs will then show up on the Bintray package page and make it easy for users to find the source.

4) How do I change the name of my plugin?

I like the convention of starting Grails plugin GitHub repos with grails- in the name. By default, Gradle takes the name of the root folder as the artifactId though. So, that would make the artifact called grails-something which obviously isn’t what we want. We want our plugin to be published as something. This is easy to fix though by creating a settings.gradle file in the root of our plugin repo with one attribute rootProject.name = "something".

5) What does “linking” my package mean and how do I get my plugin to be listed as a “Grails 3 plugin”?

Every Bintray user has their own repositories and your packages will be published to one of them. To use these binaries, you need to add your repository to your build file for dependency resolution (i.e. places to look for dependencies). Linking simply means add my package to another repository other than the one I published it to. For example, there is a big repository in Bintray called jcenter that you can link your artifacts with so that other users don’t have add your repository since a lot of people already have jcenter listed as a repository in their build file. Well, we have the same concept with the Grails Plugins repository. By linking your Grails plugin with that repository, users will not have to add your repository to find it and it will show up as a Grails 3 plugin! This is certainly not required, but it will be much easier for other community members to find and use your plugin if you link it with the Grails Plugins repository.

6) What are these “apply from: https://raw.githubusercontent.com/grails/grails-profile-repository/…” lines in my plugin build file?

Those two lines simply include bintray and publishing sections in your build file and can be considered a guide for how to configure these settings. These are actually going away for Grails 3.1+ though as there will be a new plugin for helping with publishing. You can see in this commit that I applied the same recommendation from #2 for naming Bintray packages to be just the artifactId.

7) What is the “grails-plugin” attribute in Bintray publishing?

That grails-plugin attribute is simply meta-data to query Bintray to find packages. Attributes can be added to repositories, packages and versions. In the future, if there is a separate plugin portal we can leverage the grails-plugin attribute to quickly find plugins in Bintray. Obviously having your plugin(s) added to the Grails Plugins repository in Bintray accomplishes the same thing though.

I hope you found this post helpful in answering some questions about publishing Grails 3 plugins. Thanks for reading!

Spring Session Redis with Grails 3

Fri, 04 Sep 2015 00:00:00 +0000

Managing sessions outside of your app/JVM provides flexibility with deployments and it makes both blue/green and zero downtime deployments possible. Previously, this required setting up a session manager in Tomcat, but with Grails 3 it’s much easier.

Since Grails 3 is based on SpringBoot, we can easily use the Spring Session project (along with spring-data-redis) to persist session information outside Tomcat and utilize Redis - a distributed key/value store.

Configuration:

First, lets add Spring Session and Redis to our build.gradle:

dependencies {
    compile "org.springframework.session:spring-session:1.1.1.RELEASE"
    compile "org.springframework.boot:spring-boot-starter-redis"
    ...
}

Next, tell Grails where the Redis server is located in application.yml:

spring:
    redis:
        host: localhost
        port: 6379
server:
    session-timeout: 3600 # session timeout in seconds

For Grails 3.1.x that’s it! Grails 3.0.x needs a ordering fix

Verification

Start up your app and browse to a page. You should see the session stored in Redis:

$ grails run-app
# put something on the session,
#  eg: session.foo = "bar" in a controller
#  or login to your app if you have security setup
$ redis-cli keys '*'
1) "spring:session:expirations:1441301640000"
2) "spring:session:sessions:91dcfa08-00e1-4cab-98c2-34bf0da40184"

Conclusion

With two dependancies, one class, and a little yml we’ve added the ability to store sessions outside of Tomcat and share them with multiple JVMs!

You will now be able to:

Stop and start the app and still have the values for your session
Users will not be logged out between deployments
Orchestrate a blue/green or canary deployment without downtime
Ability to share sessions across multiple JVMs on the same or different servers and round-robbin between them without loosing the session.
Redis data is persisted to disk so sessions will survive a server restart

With Grails 3 we have all the power of SpringBoot. My key takeaway from this is to not limit yourself to just Grails Plugins with a Grails 3 app and to take a look at the SpringBoot ecosystem as well.

Checkout my talk at Gr8Conf US 2015 for this and a lot of other topics related to running and building a Grails app for production.

Notes

Tested on JDK 8u60, Grails 3.1.4, Redis 3.0.3
Tested with Grails Spring Security Plugin 3.0.4
Install Redis brew install redis
Run Redis redis-server
Full working example is now in spring-session https://github.com/spring-projects/spring-session/tree/master/samples/grails3

3.0.x

To fix an ordering issue in Grails 3.0.x add a new class to tie everything together under grails-app/init/<yourapp>/SessionConfig.groovy.

package <yourapp>

import org.springframework.boot.context.embedded.FilterRegistrationBean
import org.springframework.context.annotation.Bean
import org.springframework.context.annotation.Configuration
import org.springframework.core.Ordered
import org.springframework.session.data.redis.config.annotation.web.http.EnableRedisHttpSession
import org.springframework.session.ExpiringSession
import org.springframework.session.web.http.SessionRepositoryFilter

@EnableRedisHttpSession
@Configuration
public class SessionConfig {

    /**
     * By Default SessionRepositoryFilter is registered as +50, but we need it to be before GrailsWebRequestFilter which is registered at +30. This
     * overrides the default order.
     * This override is not needed after SpringBoot 1.3.0.M5+ is included in Grails.
     */
    @Bean
    FilterRegistrationBean springSessionFilterRegistration(SessionRepositoryFilter<? extends ExpiringSession> filter) {
        new FilterRegistrationBean(filter:filter, order: Ordered.HIGHEST_PRECEDENCE + 15)
    }
}

You will need to register this bean in grails-app/conf/spring/resources.groovy or simply add @ComponentScan to your grails-app/init/<yourapp>/Application.groovy class:

...
import org.springframework.context.annotation.ComponentScan

@ComponentScan
class Application extends GrailsAutoConfiguration {
    static void main(String[] args) {
        GrailsApp.run(Application, args)
    }
}

Using Centos 7 with runnable jars in Grails 3 or SpringBoot

Fri, 15 May 2015 00:00:00 +0000

The pattern of embedding the servlet container and the application into one runnable Jar is a great way to package and run your Grails 3 / Spring Boot applications. It provides flexibility to use different containers (Tomcat, Jetty, etc) and makes deployment a breeze. We’ve been using this pattern to run applications for awhile now and wanted to share some tips for running them on Centos 7.

Running jars as a service

The first thing you’ll notice in Centos7 is that creating a service to run your app got a whole lot easier with systemd, but may feel unfamiliar at first. Here’s an example of a systemd service in /etc/systemd/system/myapp.service.

[Unit]
Description=MyApp Java Daemon

[Service]
ExecStart=/usr/bin/java -jar /opt/myapp/myapp-0.1.0.jar
User=centos

[Install]
WantedBy=multi-user.target # Similar to runlevel 5

Thats it! Much cleaner than those huge init.d scripts we’re used to.

There are a lot more options, checkout the man page here - http://www.freedesktop.org/software/systemd/man/systemd.service.html

Starting, stopping and retrieving logs has changed as well:

systemctl daemon-reload # Reload systemd config from disk
systemctl [start|stop|status] myapp.service # similar to service myapp start
systemctl enable myapp.service # set service to start onboot
journalctl -u myapp.service -f # -f tails stdout logs
journalctl -u myapp.service --since=00:00 --until=9:30 # filter on a time period

New Security settings

Centos 7 is a bit stricter with SELinux than you may be used to, which is a good thing but can catch you off guard. SELinux has been around for a while and you can fix most issues by googling them these days. Here’s a few we ran into.

Proxying from/to localhost

If you’re running nginx or apache httpd as a reverse proxy on the same host as your java app you’ll need to allow the httpd connection -

setsebool httpd_can_network_connect=1

If you’re using Chef to manage your infrastructure you can use the selinux_policy cookbook as well:

selinux_policy_boolean 'httpd_can_network_connect' do
  value true
  notifies :restart, 'service[nginx]'
end

More selinux settings can be found here - http://wiki.centos.org/TipsAndTricks/SelinuxBooleans

Permissions

Along with chown and chmod we also have chcon (change security context)

To allow httpd to read keys stored outside it’s predefined directories you can run

chcon unconfined_u:object_r:httpd_config_t:s0 /etc/pki/tls/certs/mysite.crt
chcon unconfined_u:object_r:httpd_config_t:s0 /etc/pki/tls/certs/intermediate.ca
chcon unconfined_u:object_r:httpd_config_t:s0 /etc/pki/tls/private/mysite.key

chcon changes are temporary and won’t survive if the the security context is reapplied. To permanently add this context to the system use semanage fcontext.

selinux logs

You can find the logs for selinux in /var/log/audit/audit.log. They should provide enough detail to find what you need via google.

Grails 2?

If you’re using Grails 2.x you can still build runnable jars with this plugin https://grails.org/plugin/standalone.

We hope this helps you deploying your runnable jars. If you have some other tips or need help building and deploying your Java apps drop us an email at info@agileorbit.com. I will also be speaking at GR8Conf US 2015 on this and much more http://gr8conf.us/#/talk/130

APIs with Grails 3 and OAuth 2

Mon, 11 May 2015 00:00:00 +0000

Welcome to the Agile Orbit blog! In this post, we will dive into APIs with Grails 3 and OAuth 2!

It you’re like most Grails developers, the first thing you typically do when creating a new Grails application is you install the Spring Security Core plugin. This has been great for helping jump start development, but it’s also a hinderance to actually learning the Spring Security library. As this screencast will demonstrate, you actually don’t even need plugins for security with Grails 3, but rather we can use the Spring Boot Security Starter and other Spring Security libraries directly in our Grails 3 application.

One of the goals of this screencast is to create a golden sample for Grails 3 with OAuth 2 for others to use as a starting point for their own Grails 3 APIs. If you have any ideas for improvements or additions, please feel free to fork the repo and create a pull request! As shown in the screencast, all the source-code is available in this repo:

https://github.com/bobbywarner/grails3-oauth2-api

Thanks for watching and please check back soon for more posts on the Agile Orbit blog.

Hello World

Tue, 28 Apr 2015 00:00:00 +0000

Welcome to the new Agile Orbit tech blog! Agile Orbit is a technology consulting company based out of Minneapolis, Minnesota. We bring web and mobile technology to life using innovative and cost-effective solutions. We architect, develop, and deliver software solutions for our customers using agile development, best practices, and coach teams on integrating continuous delivery into their projects

What does Agile mean?

Agile means different things to different people in the software industry. Here is what it means to us: Individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation and responding to change over following a plan. We certainly didn’t make these principles up on our own though as they are directly from the Agile Manifesto.

What does Orbit mean?

Orbit is not a common term in the software industry, but it is the term we use to describe continuous integration and continuous delivery. We believe everything in a project needs to work like an orbit. The development and release processes need to be predictable, dependable and circular. There is no such thing as one big implementation on our projects as we are continuously implementing throughout the entire project and gathering feedback from our customers at every step along the way.