Dockerfile – RUN rm not working! ex: ‘RUN rm -rf /usr/local/tomcat/webapps/ROOT’

Dockerfile – RUN rm not working! – I was going completely bananas trying to find out why a simple Dockerfile command wasn’t working.

Here is my example Dockerfile:

FROM tomcat:9
LABEL maintainer "reuben_xxx@xxx.edu"
COPY tomcat-users.xml /usr/local/tomcat/conf/
COPY server.xml /usr/local/tomcat/conf/
COPY web.xml /usr/local/tomcat/conf/
COPY context.xml /usr/local/tomcat/webapps/manager/META-INF
COPY ROOT.war /usr/local/tomcat/webapps/
RUN rm -rf /usr/local/tomcat/webapps/ROOT
RUN rm -rf /usr/local/tomcat/webapps/docs
RUN rm -rf /usr/local/tomcat/webapps/examples

These last three lines, were failing during the build, as shown here:

$ docker build -t app_name .

Sending build context to Docker daemon 52.55MB
Step 1/10 : FROM tomcat:9
9: Pulling from library/tomcat
9f0706ba7422: Pull complete
d3942a742d22: Pull complete

Step 7/10 : COPY ROOT.war /usr/local/tomcat/webapps/
---> 485815d97f89
Removing intermediate container 5ef00497c970
Step 8/10 : RUN rm -rf /usr/local/tomcat/webapps/ROOT
---> Running in 61594cd2432e
rm: cannot remove ‘/usr/local/tomcat/webapps/ROOT/WEB-INF’: Directory not empty
The command '/bin/sh -c rm -rf /usr/local/tomcat/webapps/ROOT' returned a non-zero code: 1

After some heavy google digging, which turned up a false report that this was a docker bug, I found the answer by typing docker info on the command line. Notice the warning message at the bottom of the output.

$ docker info
Containers: 1
Running: 0
Paused: 0
Stopped: 1
Images: 7
Server Version: 17.05.0-ce
...
WARNING: overlay: the backing xfs filesystem is formatted without d_type support, which leads to incorrect behavior.
Reformat the filesystem with ftype=1 to enable d_type support.
Running without d_type support will not be supported in future releases.

I ran the same Dockerfile build on a system where the file system supported d_type and the Dockerfile build worked fine. The rm (remove) command worked without error.

Before getting too deep into docker, you should ensure your filesystem supports d_type – use OverlayFS storage driver.

The file system should be formatted with ftype=1 or d_type=true. Docker will not support running without d_type support in future releases.

Feel the breeze!
Reuben

Hard drive vs SSD vs M.2 Speed Test Using CrystalDiskMark5

M.2 SSDs are blazing fast….
Top drive test is a standard (with spinning platters) Western Digital 500GB hard drive (WD5000AAKS-00TMA) .
Middle is an older OCZ 500GB SSD, solid state hard drive with no spinning data platters (OCZ-AGILITY3).
Last but not least, on the bottom test is my newest technology SSD type, Intel 1TB M.2 SSD (SSDPEKKW010T7). This SSD looks like this and plugs directly into an M.2 slot on the motherboard.
 
As you can see from the read / write results below, the SSDs are in a different league as far as speed with regular hard drives… To put that in perspective, I boot the bottom drive into a Windows 10 Pro 64 Bit environment in less then 10 seconds from being powered off.
That’s pretty amazing…

CrystalDiskMark5 Test Results

 

These are the types of various tests preformed above (Using CrystalDiskMark5):

  • Seq Q32T1: Sequential (Block Size=128KiB) Read/Write with multi Queues & Threads
  • 4K Q32T1: Random 4KiB Read/Write with multi Queues & Threads
  • Seq: Sequential (Block Size=1MiB) Read/Write with single Thread
  • 4K: Random 4KiB Read Write with single Queue & Thread
My system information is as follows for your reference purposes:
Yes, I have 32gb of ram – (I do a lot of multi-tasking)
:0)
Pleasant ones….

In search of an iOS – iPhone / iPad WiFi Scanner….. wifi scanner – iPhone iPad iOS wi-fi scanner Wi-Fi Scanner

Years ago, when the iPhone and iPad were first introduced, Apple allowed programmers to create apps that allowed wifi scanning. Sometime later, these types of apps started slowly disappearing one by one from the app store. I believe Apple started to restrict access to the wifi portion of their api. I was luckily grandfathered in for a couple of years with an original wifi scanner that I had on my iPhone (pre-restriction), but alas, it stopped working when their api was updated.

The good news….I found one!!!

For sometime, I’ve been looking for a wifi scanning tool for my iPhone and iPad. These tools can help you setup your wifi network, and gather information about any wifi network that you may be connected to. For example, the wifi channel, the MHz (2.4MHz or 5Mhz), the mac address of the adapter you’re connected to, signal strength, etc…

There is a wifi scanner ‘hidden’ inside Apple‘s app called ‘AirPort Utility‘!!! Apparently, Apple is not under the same restrictions as other app developers.

Here’s how to get it installed on your iPhone / iPad – no jailbreak needed, lol…

So here’s what the app looks like in the App Store:

image3

Once you download it, you MUST go into your iPhone settings and click on the ‘AirPort Utility‘ settings:

image1

Then, turn on the Wi-Fi Scanner!  — Bam! (feel good yet?)

image2

Once this setting is on, launch the actual AirPort Utility app and click Wi-Fi Scan in the upper right hand corner.

image4

You’ll then have access to network meta-data such as the wifi channel, the MHz (2.4MHz or 5Mhz), the mac address of the adapter you’re connected to, signal strength, etc…

You can determine whether the network is 2.4MHz or 5Mhz by looking at the channel numbers… 2.4GHz channels are usually numbered 1-14 whereas 5GHz channels are usually numbered between 34-216.

image5 image6

Check it out! Have fun, and please use this tool wisely, for good and not evvvvvvil!

Till next time, pleasant ones…  :0)

Finding the full paths for running processes in unix

Finding the full paths for running processes in unix…

Let us say that you wanted to find the processes that were running with the string classpath in it. You could or might type something like:

$ ps -eaf |grep -i 'classpath'

This would give you a list of all running processes where the string classpath were present… similar to this output:

ps_1

Notice the line above with the long classpath, it gets cut off after ‘…/opt/sgh…’. This can be very annoying, because there are times when you will need the full line for whatever your reasons!

Next time, try typing this instead:

$ /usr/ucb/ps -aux -www |grep -i 'classpath'

This should give you the full line in the output as in the example below:

ps_2

Notice in the above output, you’ll see the full line of the process, which allows you to see the full classpath, where before it was getting cut off…

Pleasant ones…. :0)

Cleaning up after Docker – Commands

Cleaning up after Docker – Commands

After playing around with Docker these last few months something that I find annoying is these unused containers and images taking up valuable disk space.

Here are some commands that will help you clean this all up:

Kill all running containers:
$ docker kill $(docker ps -q)

Delete all stopped containers (including data-only containers):
$ docker rm $(docker ps -a -q)

Alternative to previous: Delete old docker containers that have been running in the past (weeks, hours, months, etc…). Vary the word after ‘grep’ to target the containers you want to remove – example: use ‘months’, ‘weeks’, ‘hours’, ‘minutes’, etc… depending on the age of the container that are running. Use docker ps -a to check this first.

$ docker ps -a | grep 'hours' | awk '{print $1}' | xargs --no-run-if-empty docker rm

$ docker ps -a | grep 'weeks' | awk '{print $1}' | xargs --no-run-if-empty docker rm

Delete all ‘untagged/dangling’ (<none>) images:
$ docker rmi $(docker images -q -f dangling=true)

Delete ALL images (be careful with this):
$ docker rmi $(docker images -q)

Enjoy Docker!

Checking for an open / listening port

Checking for an open / listening port….

I’ve had many occasions dealing with network administrators asking them for ports to be open on the firewall so outside users can connect and communicate with various web services. For example, when putting a tomcat site up on port 8080 (this could easily be port 80, 443 or any other port for that matter). I needed the network admin to open port 8080 on the firewall to the outside world…

At that point, if I still could not connect to the website, I needed a way to debug. My first question was always, ‘did he open the port?’, and ‘is the website listening on the correct port 8080?’

How do I really know if the port is open / listening?? How do we know for sure if the firewall rule was done properly and working?

Well here’s a trick I learned using telnet which is readily available on most machines, Windows, Mac, Linux, Red Hat, etc….

At any command prompt type:
# telnet <fill-in-the-ip-address-or-dn-name-here> 8080

<fill-in-the-ip-address-or-dn-name-here> should be the ip address or the domain name of the server that you are testing connectivity to.

For example:

telnet_1

You will receive a different response depending on the host’s operating system you’re typing the telnet command on. Also, the response will vary depending on if the port is open or close and there is a service listening on the port.

In Windows, a response like this means the port is open and listening on the targeted server and port:

telnet_2

After the telnet command the screen will go blank if the port is open / listening.

In Unix / Linux the response will look like this if the target port is open and listening:

telnet_4

In both Windows and Unix style operating systems, if the port is not listening the response will look something like this:

telnet_3

In other words, there really won’t be any response. It will just freeze at the ‘Connecting to’ xxx.xxx.xxx.xxx line.

Enjoy!

Link docker containers via their internal ip address

There could come a time when you’ll need to link two or more docker containers. For example, you have a database and a web-service running in separate docker containers. The web-service needs data from the database to serve up its services to a third container which is running a tomcat website. This is known as a ‘micro service application architecture‘.

Let’s link docker containers!

Here’s a simple example of two containers  – one being able to see the other over their own private internal network.

First, let’s spin up a postgres database container in daemon mode (back ground process (-d) ). Let’s name the database container ‘database’.

# docker run -d --name database postgres:latest

postgres

Let’s check to ensure it’s running:

# docker ps

db_running

Yay! There it is…
Now let’s inspect the database container and see the container’s ip address:

# docker inspect database |grep IPAddress

db_ip

As you can see, the database container’s ip address is 172.17.0.10.

Now let’s spin up another container, this time a make believe web-service container running on uBuntu and enter into a bash shell within that container. We will link the web-service container to the database container with the ‘–link’ argument of docker:

# docker run -it --name webservice --link database:db ubuntu:14.04 bash

ubuntu_con

As you can see, I now have a bash shell prompt inside the ‘web-service’ container.

If we check the /etc/hosts file inside the web-service container, we’ll see an entry to the postgres database container. This was automatically added because we used the ‘–link’ argument when we spun up the web-service container.

# cat /etc/hosts

etc_hosts

Please notice the last entry in the /etc/hosts file. You’ll see 172.17.0.10, the database container ip address – cool! This entry will allow the web-services container to communicate with the database container.

The ‘db’ to the right of the database container’s ip address is the alias we assigned in the ‘–link database:db’ argument when we ran the web-service container. ‘database‘ is the our docker name of the postgres container and ‘db‘ is the local alias name we assigned.

Let’s check out the web-service container’s ip address is:

# ifconfig -a |grep inet

web_ip

You’ll notice the web-service container ip address is 172.17.0.12.

OK, let’s try to ping the database container from the web-services container:

# ping 172.17.0.10

ping

As you can see, the web-services container can see the database container!

Hooray, they can see each other!

The web-service container will be able to access the database container.

Eureka!

Stop uBuntu from asking for your sudo password

If you’re like me and are tired of having to enter your sudo password each and every time you run a sudo command please find the steps below to ease your frustrations on this matter.

Please note, this is not recommended for public access computers or work computers. This is a nice modification for home uBuntu systems.

Launch a terminal window. I use putty remotely or uBuntu terminal locally.

$ sudo visudo

visudo is a command used to edit the config for sudo.

Go to the bottom of the config file and add this:

username ALL=NOPASSWD: ALL

username’ should be replaced with the username of the user you want to allow a passwordless sudo. So if the user is reuben, you would enter:

reuben ALL=NOPASSWD: ALL

Save and exit – log out and log back in as the user and test out the passwordless sudo access.

bash into a running docker container

First off, what the heck is Docker? It’s amazing, that’s what it is…
Check it out – you won’t be sorry…

Docker is an open platform for developers and sysadmins to build, ship, and run distributed applications, whether on laptops, data center VMs, or the cloud.

There are several reasons why you might want a bash shell command prompt in a running docker container. One is of course to modify the container and then commit it to a new image.

$ sudo docker exec -i -t 6c3c89dc97d9 bash #by ID
or
$ sudo docker exec -i -t loving_dianne bash #by Name

bash

to exit back to your local-host command prompt:

$ exit