CentOS/RedHat make port 8080 visible

I am a happy DigitalOcean customer primarily because of the low cost, the SSD drives, the friendly stuff and the flexibility by which you can reshape your purchased resources into droplets within the 4 DataCenters (2 in NY and 2 in Amsterdam) supported.

Until the need for a UK DataCenter arises which leads me to RackSpace.

On both private cloud hosting providers I am making a web service available that needs to be accessible @ port 8080. The CentOS flavour assembled in DigitalOcean has everything permitted by default in its iptables settings but the one assembled in RackSpace does not.

When I issue the iptables command I get:

[dimitrisli@lon1 ~]# iptables -L -n --line-numbers
Chain INPUT (policy ACCEPT)
num target prot opt source destination
2 ACCEPT icmp --
3 ACCEPT all --
4 ACCEPT tcp -- state NEW tcp dpt:22
5 REJECT all -- reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT)
num target prot opt source destination
1 REJECT all -- reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
num target prot opt source destination

And just by adding permission for port 8080 will put it by default under the last reject input policy so the correct command should be putting the permission at the current spot of the reject input policy:

[dimitrisli@lon1 ~]# iptables -I INPUT 5 -m state --state NEW -m tcp -p tcp --dport 8080 -j ACCEPT -m comment --comment "Jetty Server port"

[dimitrisli@lon1 ~]# service iptables save

that eventually does the trick.

CentOS/RedHat screen command

Install screen:

yum install screen.x86_64

Create a screen by giving it a name:

screen -S process1

Detach from the current screen:

shortcut: Ctrl + A + D

Inspect running screens:

screen -ls

There is a screen on:
11174.process1 (Detached)
1 Socket in /var/run/screen/S-root.

Reattach to running screen per name:

screen -R process1

Homebrew: Install the Typesafe Stack

Old news: New machine -> new setup
Exciting alternatives: Homebrew -> “Typesafe Stack”

brew install scala sbt maven giter8

Homebrew is a package manager that keeps things tidy under the /usr/local/ directory, which is what we are using here to have Scala and friends installed. giter8 is a template Github archetype-maven-like command line tool that grows up to be the defacto way of bootstrapping a Scala-related project.

Installing Homebrew in Mac OS X 10.9 (Mavericks)

Installing Homebrew in previous OS X versions was holding a dependency on having Xcode pre-installed which is a substantial dependency (in terms of volume size) especially considering that you might not even be using this IDE as was always my case.

Not any more.

Apparently the Xcode part that is needed by Homebrew and other 3rd party tools, dubbed Command Line Tool in the net, has been extracted from Xcode and is being made available via the simple Terminal command in Mac OS X 10.9:

xcode-select --install

that pops up a pane to confirm auto-download of the tool.

From that point onwards Homebrew installation can continue with the ruby script as it was always the case. After installation completes ‘brew doctor’ can assure you that all is good and you can start amassing Cellars for the brewing process.

Tennis Historical Data Retriever in Scala

Here’s a quick and dirty Tennis historical data retriever:

package data.analysis.tennis
import scala.io.Source
import java.util.Date
import java.text.SimpleDateFormat
object TennisDataAnalysis extends App{
  def wrapStringInt(stringInt:String) = if(stringInt=="") None else Some(stringInt.toInt)
  case class TennisMatch(location:String, tournament:String, date:Date, series:String,
                         surface:String, round:String, bestOf:Int, winner:String, loser:String,
                         W1:Option[Int], L1:Option[Int], W2:Option[Int], L2:Option[Int], W3:Option[Int],
                         L3:Option[Int], W4:Option[Int], L4:Option[Int], W5:Option[Int], L5:Option[Int],
                         Wsets:Option[Int], Lsets:Option[Int], comment:String)
  val sourceSite = "http://www.tennis-data.co.uk/"
  val years = List(2010,2011,2012,2013)
  val tournaments = List("ausopen","frenchopen","usopen","wimbledon")
  val urls = years.map(year => sourceSite+year+"/").flatMap(urlYear => tournaments.map(tours=> urlYear+tours+".csv"))
  val data =
    urls.flatMap{urlYearTour =>
        .map{g => TennisMatch(g(1), g(2), new SimpleDateFormat("dd/mm/yyyy").parse(g(3)), g(4),
                          g(6),g(7),g(8).toInt, g(9), g(10),
                          wrapStringInt(g(15)), wrapStringInt(g(16)), wrapStringInt(g(17)), wrapStringInt(g(18)),
                          wrapStringInt(g(19)), wrapStringInt(g(20)), wrapStringInt(g(21)), wrapStringInt(g(22)),
                          wrapStringInt(g(23)), wrapStringInt(g(24)), wrapStringInt(g(25)), wrapStringInt(g(26)),

Synology, VirtualBox and iSCSI

This is a tutorial on how to setup your VirtualBox VMs to run off your Synology NAS via the fast iSCSI protocol.

What is VirtualBox? VirtualBox is a high performant, free, easy and at the same time versatile virtualisation solution.
Why VirtualBox? Because it’s free, easy to setup, cross-platform product that you can install at home/work and hasn’t let me down yet.
What is Synology? Synology is a company that produces high quality NAS drives.
Why Synology? Although not cheap, their NAS solutions are a good marriage between hardware and tailored-made actively maintained software. You can read further details on my Amazon review.
What is iSCSI? SCSI is a protocol for fast communication between hard drives and computers. iSCSI is a protocol that allows SCSI commands over the wire (Internet/WAN/LAN).
Why iSCSI? Don’t take my word for it, if you own an external HD or a NAS try storing the VMs there and point to them as mounted drives from VirtualBox. The latency will give you an answer.

Now that we got the theory out of the way let’s start with the setup!

First stop, Synology DSM > Start Menu top left > Storage Manager > iSCSI LUN tab


Then we create a new iSCSI LUN. In the wizard that pops up there is only one option available for me since I’ve gone for the SHR (Synology Hybrid Raid) while I was first setting up my drives. If you’ve gone for one of the vanilla Raid options you’ll be getting two more options to chose from:


Next we give a descriptive name to the LUN to remind us what that slice in our NAS will be hosting, in my case it will be a CentOS latest distro for the MacbookPro non-x64 compatible architecture. We also setup the size (10GB in our example):


The iSCSI LUN that we are about to create will be associated with an iSCSI Target that our VirtualBox client will be connecting to. Following the same pattern of giving a descriptive name and letting the IQN identifier to its default generated one:


The next screen will be a summary page:


Our newly created iSCSI LUN shows now up on the Storage Manager tab list:


Same goes for the associated iSCSI Target that was auto-generated:


Our job is done in the Synology NAS, let’s head now to the VirtualBox:



Next we have to tell VirtualBox not to rush and attach any drive yet since we’ll need to configure it first (unfortunately we can’t do that currently from the VirtualBox GUI):


VirtualBox draws our attention that we’ll have to setup the drive eventually:


The VM now is successfully created, but we’re not done just yet:


Next by right clicking on the VM > settings > storage tab we note down the name of the SATA controller (in our case simply set it up SATA).


Here comes the hard part of the tutorial. We have to tell VirtualBox that our newly created VM will be using an iSCSI LUN slice created on our NAS. This step truly needs to be easy and intuitively done via the VirtualBox GUI but currently the functionality is not there. That’s where we need to rely on a command line VirtualBox command to set this up. The command is called VBoxManage that is visible in MacOSX Terminal after we install VirtualBox. In the Windows systems we’ll have to use the command prompt navigating first to the bin directory of VirtualBox where the VBoxManage command lives. Here’s the full command with further explanations of all the needed options:


Here’s the command in text (be careful to replace: 1. the name of the VM, 2. the name of the SATA controller, 3. the NAS IP address, 4. the IQN your NAS has set):

VBoxManage storageattach "CentOS-6.4-i386" --storagectl "SATA" --port 0 --device 0 --type hdd --medium iscsi --server --target "iqn.2000-01.com.synology:ZeusData.name" --tport 3260

The command replies back with a unique identifier and a short message of success:


Let’s restart now VirtualBox and take a look at the properties of the VM.

VM > settings > storage tab. Now we see the iSCSI target appearing and also notice how VirtualBox is picking up the size of the LUN set by our Synology configuration to be 10GB:


All is done now, let’s start the VM:



A final thing to mention is that while the VM is running, Synology DSM is capturing on-the-fly the iSCSI target device/status:


In case you want to erase the VM, before deleting the SATA controller and the VM itself from VirtualBox, with VirtualBox closed execute the following command (same as the one previously presented but with the argument ‘none’ for medium):

VBoxManage storageattach "CentOS-6.4-i386" --storagectl "SATA" --port 0 --device 0 --type hdd --medium none --server --target "iqn.2000-01.com.synology:ZeusData.name" --tport 3260

Following this activity the VM, SATA controller in VirtualBox as well as the iSCSI LUN/Target in Synology can be deleted.