Happy Thanksgiving!

rstaatsUncategorized0 Comment

Well dear friends in operations/systems/devops/sysops/SREs etc, it’s that time of the year again. The time when traffic swells, auto-scaling, monitoring, and all the hard work we do day in and day out matters the most. Oh, well and there’s turkey and family too. But for those of us in the trenches keeping holiday shopping online I raise my cup of strong coffee and wish you quiet pagers, solid uptimes, happy customers, and wish you a happy holiday weekend. See you on the other side of the black week!

 

And of course if you need some comedic relief….

Use Java 6u65-apple with SKDMan on Mojave/High Sierra/Sierra/El Capitan

rstaatsUncategorized1 Comment

If you work in and around the world of Java, Groovy, Spring MVC, Grails, or Gradle you are bound to use a tool like sdkman when juggling multiple versions of these applications. If you haven’t used it before it’s worth taking for a spin. You can run simple commands like sdk install grails or sdk use java 8.0.181-zulu. This is great except that Java 6 isn’t really supported in sdkman for Mac. Queue the simple workaround!

Install SDK Man if you are not already using it, link is here

Go to the Apple Download page for Java 6 here

Next you will want to open terminal and do the following:

 cd ~/.sdkman/candidates/java/

Next you will create the following symlink:

 ln -s /Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/ 6u65-apple

If this is successful you should be able to see it in the list when running sdk list java. Next we can verify that this worked successfully:

sdk use java 6u65-apple

You should now see a green print statement that reads “Using java version 6u65-apple in this shell. You can further validate that its working by running java -version. Your output should resemble the below:

java -version
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-468)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-468, mixed mode)

Nginx Requests Not Being Gzipped on CDN Pass-Through

rstaatsDevops, Linux0 Comment

A couple months ago I ran into a curious situation. Requests from Nginx were being gzipped as expected and requests from CDN were being gzipped. My Nginx settings for compression looked like this:


gzip on;
gzip_comp_level 6;
gzip_http_version 1.1;
gzip_min_length 0;
gzip_types application/json application/x-javascript application/javascript text/plain text/css text/javascript text/xml;
gzip_vary on;
gzip_disable "MSIE [1-6]\.";

Reproducing the behavior was simple enough. If you hit the URI at CDN and append a cache busting string to the end of the URI such as \?2342343243 the headers would return without the Content-Encoding: gzip header. Another test to confirm this was to use a curl statement passing the via header with any value such as below

 

curl -v -H “Accept-Encoding: gzip” -H “Via: 1.1 akamai.net(ghost) (AkamaiGHost)”  "http://youruri.com”

A simple explanation of this issue is that when request hits the CDN and the object is not cached, the request is then passed to origin using the via header. Unless the Nginx gzip directive of gzip_proxied any; is included this request will always be sent uncompressed. To resolve add this line to your nginx.conf file. Below is the same example shown earlier but including this directive:


gzip  on;
gzip_comp_level 6;
gzip_http_version 1.1;
gzip_min_length 0;
gzip_types application/json application/x-javascript application/javascript text/plain text/css text/javascript text/xml;
gzip_proxied any;
gzip_vary on;
gzip_disable "MSIE [1-6]\.";