Downgrade to openjdk 8 for Jenkins on Ubuntu 18 Bionic

On my Ubuntu 18 Bionic server, I installed Jenkins. Upon completion of the installation, there was error message that goes something like this:

Output from sudo journalctl -xe

 Feb 19 14:10:17 macmini.shinstudio.lan jenkins[21270]: OpenJDK 64-Bit Server VM (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4, mixed mode)
Feb 19 14:10:17 macmini.shinstudio.lan jenkins[21270]: Aborting
Feb 19 14:10:17 macmini.shinstudio.lan systemd[1]: jenkins.service: Control process exited, code=exited status=1
Feb 19 14:10:17 macmini.shinstudio.lan systemd[1]: jenkins.service: Failed with result 'exit-code'.
Feb 19 14:10:17 macmini.shinstudio.lan systemd[1]: Failed to start LSB: Start Jenkins at boot time.
-- Subject: Unit jenkins.service has failed
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
-- 
-- Unit jenkins.service has failed.
-- 
-- The result is RESULT.
Feb 19 14:10:18 macmini.shinstudio.lan systemd[1]: Reloading.
Feb 19 14:10:18 macmini.shinstudio.lan systemd[1]: Starting resolvconf-pull-resolved.service...
-- Subject: Unit resolvconf-pull-resolved.service has begun start-up
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
-- 
-- Unit resolvconf-pull-resolved.service has begun starting up.
Feb 19 14:10:18 macmini.shinstudio.lan systemd[1]: Started resolvconf-pull-resolved.service.
-- Subject: Unit resolvconf-pull-resolved.service has finished start-up
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
-- 
-- Unit resolvconf-pull-resolved.service has finished starting up.
-- 
-- The start-up result is RESULT.
Feb 19 14:10:22 macmini.shinstudio.lan sudo[19303]: pam_unix(sudo:session): session closed for user root
Feb 19 14:10:28 macmini.shinstudio.lan kernel: [UFW BLOCK] IN=enp0s10 OUT= MAC=01:00:5e:00:00:01:f0:9f:c2:c6:9e:f4:08:00 SRC=192.168.1.101 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 I
Feb 19 14:11:19 macmini.shinstudio.lan sudo[21416]: shane : TTY=pts/0 ; PWD=/var/log/jenkins ; USER=root ; COMMAND=/bin/systemctl start jenkins
Feb 19 14:11:19 macmini.shinstudio.lan sudo[21416]: pam_unix(sudo:session): session opened for user root by shane(uid=0)
Feb 19 14:11:19 macmini.shinstudio.lan systemd[1]: Starting LSB: Start Jenkins at boot time...
-- Subject: Unit jenkins.service has begun start-up
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
-- 
-- Unit jenkins.service has begun starting up.
Feb 19 14:11:19 macmini.shinstudio.lan jenkins[21419]: Found an incorrect Java version
Feb 19 14:11:19 macmini.shinstudio.lan jenkins[21419]: Java version found:
Feb 19 14:11:20 macmini.shinstudio.lan jenkins[21419]: openjdk version "10.0.2" 2018-07-17
Feb 19 14:11:20 macmini.shinstudio.lan jenkins[21419]: OpenJDK Runtime Environment (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4)
Feb 19 14:11:20 macmini.shinstudio.lan jenkins[21419]: OpenJDK 64-Bit Server VM (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4, mixed mode)
Feb 19 14:11:20 macmini.shinstudio.lan jenkins[21419]: Aborting
Feb 19 14:11:20 macmini.shinstudio.lan systemd[1]: jenkins.service: Control process exited, code=exited status=1
Feb 19 14:11:20 macmini.shinstudio.lan sudo[21416]: pam_unix(sudo:session): session closed for user root
Feb 19 14:11:20 macmini.shinstudio.lan systemd[1]: jenkins.service: Failed with result 'exit-code'.
Feb 19 14:11:20 macmini.shinstudio.lan systemd[1]: Failed to start LSB: Start Jenkins at boot time.
-- Subject: Unit jenkins.service has failed
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
-- 
-- Unit jenkins.service has failed.
-- 
-- The result is RESULT.
Feb 19 14:11:29 macmini.shinstudio.lan kernel: [UFW BLOCK] IN=enp0s10 OUT= MAC=01:00:5e:00:00:01:f0:9f:c2:c6:9e:f4:08:00 SRC=192.168.1.101 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 I
Feb 19 14:11:33 macmini.shinstudio.lan sudo[21467]: shane : TTY=pts/0 ; PWD=/var/log/jenkins ; USER=root ; COMMAND=/bin/journalctl -xe
Feb 19 14:11:33 macmini.shinstudio.lan sudo[21467]: pam_unix(sudo:session): session opened for user root by shane(uid=0)

The first thing I noticed was the Java version, which is 10.0.2+13-Ubuntu… In the past when I worked with Jenkins, JDK was mostly 8. So, I googled about JDK 10+ and Jenkins and found this link. I thought that the content was not convincing me much whether JDK 10+ would work well with Jenkins…

I decided to downgrade to JDK 8 and here’s what I did (did not actual uninstall JDK 10 and reinstall JDK 8)

sudo update-alternatives –config java
There are 2 choices for the alternative java (providing /usr/bin/java).

Selection Path Priority Status
————————————————————
* 0 /usr/lib/jvm/java-11-openjdk-amd64/bin/java 1101 auto mode
1 /usr/lib/jvm/java-11-openjdk-amd64/bin/java 1101 manual mode
2 /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java 1081 manual mode

Press to keep the current choice[*], or type selection number: 2
update-alternatives: using /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java to provide /usr/bin/java (java) in manual mode

[20] ? java -version
openjdk version “1.8.0_191”
OpenJDK Runtime Environment (build 1.8.0_191-8u191-b12-0ubuntu0.18.04.1-b12)
OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)

After confirming java executable points to 1.8 instead of 10/11, I started Jenkins successfully.

[21] ? sudo systemctl start jenkins 
[22] ? ps aux | grep jenkins
jenkins  21545  0.2  0.2  76632  7640 ?        Ss   14:14   0:00 /lib/systemd/systemd --user
jenkins  21546  0.0  0.0 257560  2936 ?        S    14:14   0:00 (sd-pam)
jenkins  21561  0.0  0.0  19096   188 ?        S    14:14   0:00 /usr/bin/daemon --name=jenkins --inherit --env=JENKINS_HOME=/var/lib/jenkins --output=/var/log/jenkins/jenkins.log --pidfile=/var/run/jenkins/jenkins.pid -- /usr/bin/java -Djava.awt.headless=true -jar /usr/share/jenkins/jenkins.war --webroot=/var/cache/jenkins/war --httpPort=8080
jenkins  21562  100  3.0 2953332 114708 ?      Sl   14:14   0:13 /usr/bin/java -Djava.awt.headless=true -jar /usr/share/jenkins/jenkins.war --webroot=/var/cache/jenkins/war --httpPort=8080
shane    21617  0.0  0.0  13136  1088 pts/0    S+   14:14   0:00 grep --color=auto jenkins

No error and Jenkins is up and running!

RancherOS

Recently I got to know about RancherOS, which is an OS that provides pretty much only Docker host environment so that you can launch Docker containers.

My test environment is Mac OS Sierra with VMWare Fusion 8.5. What I did was as follows:

  1. Download ISO file for RancherOS
  2. Launch ISO via VMWare Fusion with 1GB ram and 10GB disk space (That’s normally what I use for linux distribution guest environment)
  3. Once I was on RancherOS terminal, I created cloud-config.yml file with ssh publick key in it. (Refer to the instruction)
  4. I made a note of IP address for the step #5
  5. After installing to the disk, I chose to reboot. From Mac terminal, I ssh’ed to the IP address of the RancherOS guest after RancherOS guest became available.

Pretty straightforward to install RancherOS on my mac.

RancherOS provides its own command line tool called ‘ros’ and this is the tool to configure the system, docker, etc.

Sync up Docker container time with Host’s

I’ve had some issues with my application’s user session being expired as soon as it got created. After further investigation, it was due to the fact that docker container’s time was far behind the current PDT(which is where I am and a default timezone for all my servers).

Easiest solution was to mount these two files from host to any containers:

After the two lines of docker volume, viola. Time synced between host and container.

Bye bye data-only container! Hello named volume!

Persistent data practice that I’ve been using with Docker has been the host volume although I knew that data-only container pattern existed.

So this time around, I was going to start utilizing data-only container pattern for some of db containers. However, I got to know that after docker version 1.9.0.

For example with data-only container pattern, we would have a docker-compose file like this:

However, a better approach would be:

New way of web application deployment: “Bakery” process

I have been quite interested in continuous deployment and working on ‘bakery’ process using OpenStack (which is another cloud environment comparable to AWS).

A traditional way of deployment is normally:

  • pull source code from source management on production env
  • create a tar file and then scp it & remote execute a script to untar
  • create a debian or rpm package, and then remote install it

They are ok ways, but main issue with them seems to be ability to keep multiple environment consistent and slow deployment processes.

Continue reading

vmware fusion and shared directory on a host machine

I’m using vmware fusion to create many development environments so that I have completely isolated ubuntu for client A, windows 2008 server R2 for client B, centos for client C, and so on.

Actually it was several months ago, but I was bothered to find a solution to this weird bug couple days.

On vm ubuntu, every time I use *composer* to update PHP project dependencies I end up with php parse error. They look something like this:

  • PHP Parse error: syntax error, unexpected ‘)’ in …
  • PHP Parse error: syntax error, unexpected ‘F’ in …
  • PHP Parse error: syntax error, unexpected $end
  • and so on…

BTW the temporary solution was to open a file, save, and then quit vim.

To fix the issue better than the temporary solution was:

  1. sudo vmware-uninstall-tools.pl (on the vm ubuntu)
  2. sudo apt-get install open-vm-tools

Since then I have not had the same issue before. Some reported that the solution that I took steps stopped working for them, but it wasn’t the case for me.

laravel’s database migration and seed

I have not used laravel 4’s migration and seed features much until couple days ago.
Oh boy, it’s a really sexy tool.

It does not matter whether you are in a team or you are all alone doing everything. It’s a feature that every single develop must use if integrating with a database!

Theoretically if you are a disciplined developer and use those features, confidence level of your database changes when deploying will be very high. I promise!

You will end up needing these if you decide to go with it:

*migration* file should be used for any changes that affect db schemas.
*seeding* file should be used to pre-populate data into db.

UPDATE #1:
I thought it’d be beneficial to add some sample codes.

To create migration file, run this at Laravel’s app directory:

The above command line creates a file something like:

And its content looks something like this:

As you can take a guess, up method is where you change db schema. down method is where you rollback the change.

So let's say I want to add column "username" to "users" table.

(If you want to know more about available methods to manipulate db schema, click here.)

Now you want to run against your db? Then don't look further. Just run this:

After you run the command line, Laravel adds that particular code to migrations db table and that's how it keeps track of history.

Now you realize that you made a mistake and want to rollback your last change, run this:

I'll add seeding sample to the blog post later...