How to Install Apache Tomcat on Mac OS Sierra

Our previous tutorial on installing Tomcat on El Capitan had a lot of interest, so here it is an updated (but broadly similar) tutorial for MacOS Sierra.

In this tutorial, we will be using the open-source package manager Homebrew. If you’re not already using homebrew, check out its popularity on GitHub. It’s highly recommended for use with developing on Macs as it makes keeping track of installed software 100 times cleaner than doing it manually (everything is stored in one place, packages are easy to remove, upgrade and find configs for).If you don’t already have Homebrew, install it with:

First, open your Mac terminal window. If you don’t already have Homebrew, install it with:

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"


Step 1: Install Tomcat

Now we can easily install and track the version of Tomcat we’re using and config files etc with the following command:

brew install tomcat

This will take care of the downloading, installation and configuration of Tomcat and manage its dependencies as well. Take note of the output, brew commands are typically really good at displaying concise but useful info, errors and other help.

Homebrew keeps all installed packages (called “kegs”) in a “Cellar” folder – they like their beer references. By default, this is located in the /usr/local/ directory, so there should now be a tomcat folder listed by the command:

ls /usr/local/Cellar

Although an easier shortcut is available as:

brew list

To get more info on Tomcat specifically:

brew list tomcat

This should output something similar to:

$ brew list tomcat
/usr/local/Cellar/tomcat/8.5.15/bin/catalina
/usr/local/Cellar/tomcat/8.5.15/libexec/bin/ (15 files)
/usr/local/Cellar/tomcat/8.5.15/libexec/conf/ (10 files)
/usr/local/Cellar/tomcat/8.5.15/libexec/lib/ (25 files)
/usr/local/Cellar/tomcat/8.5.15/libexec/temp/safeToDelete.tmp
/usr/local/Cellar/tomcat/8.5.15/libexec/webapps/ (573 files)
/usr/local/Cellar/tomcat/8.5.15/RELEASE-NOTES
/usr/local/Cellar/tomcat/8.5.15/RUNNING.txt

The listed binary file Catalina is the “servlet container” used to run the Apache Tomcat server. This can now be started using the command:

catalina run &

The ampersand at the end makes the process run in the background, so after pressing the return key you get your terminal back but Catalina is still running in the background, you can remove it if you want to keep a dedicated window on the process.

Catalina can be stopped using:

catalina stop

 

Step 2: Configure Tomcat

Apache Tomcat comes with an inbuilt GUI management suite, however, for security reasons, this is disabled by default (to avoid dangerous default usernames/passwords). To enable the GUI manager, first edit the file:

nano /usr/local/Cellar/tomcat/8.5.15/libexec/conf/tomcat-users.xml
  • Nano is a text editor that comes with MacOS, although any will do.
  • If the file is blank or not found, you probably have a slightly different version of Tomcat installed, hit ctrl + x to exit, then run the command brew list tomcat and replace the above version number with the one you have installed.

Scroll to the bottom of the file and you should see several user entries surrounded such as:

<!–
<role rolename=”tomcat”/>
<role rolename=”role1″/>
<user username=”tomcat” password=”<must-be-changed>” roles=”tomcat”/>
<user username=”both” password=”<must-be-changed>” roles=”tomcat,role1″/>
<user username=”role1″ password=”<must-be-changed>” roles=”role1″/>
–>
</tomcat-users>

The <!– …  –> means these users are commented out. Leave them as they are and add a new entry after but above the </tomcat-users> line with the “manager-gui” role:

<user username=”someUser” password=”somePassword” roles=”manager-gui”/>

So the file now looks like:

<!–
<role rolename=”tomcat”/>
<role rolename=”role1″/>
<user username=”tomcat” password=”<must-be-changed>” roles=”tomcat”/>
<user username=”both” password=”<must-be-changed>” roles=”tomcat,role1″/>
<user username=”role1″ password=”<must-be-changed>” roles=”role1″/>
–>
<user username=”someUser” password=”somePassword” roles=”manager-gui”/>
</tomcat-users>

Obviously, you should use a unique username & password for security!

Now, start Catalina again:

catalina run
  • If you get errors, you probably need to stop it first, use catalina stop
  • By default, Tomcat runs on port 8080. There’s a really useful command to see what services are running on this a port: lsof -i :8080 (you may need to prefix with sudo for admin protected ports like 80).

Now if you go to the following page you should see a management GUI:

http://localhost:8080/manager/html

Here you can deploy .war files or exploded directories using the Deploy console and existing servlets are listed. You can even try visiting the already deployed servlets by appending the listed path to localhost:8080 (the default tomcat port):

So, the following should give the docs & some examples:

http://localhost:8080/docs
http://localhost:8080/examples

Enter the .war file location you wish to deploy and the desired path into the Deploy section and your application should now be listed as running with its path. Additionally, this can be used with an IDE like Netbeans or IntelliJ to run & debug servers using their configuration windows.

Any questions, please ask in the comments, and please share this article if you found it helpful.

Advertisements

PBCopy Mac command

A couple of useful Mac terminal (or iTerm) commands are the PBCopy & PBPaste. Here is a demonstration of how they work.

There are two basic ways to copy using pbcopy:

$ pbcopy < source_file.txt
copies text in source_file.txt

$ pwd | pbcopy
copies the output from pwd (the current directory) to the Mac clipboard

The copied text can now be pasted (either using menu’s or the CMD + V keyboard shortcut) into other applications in the usual way.

PBPaste works using the same syntax but in reverse:

$ pbpaste > destination_file.txt
pastes the current Mac clipboard to destination_file.txt

$ cd `pbpaste`
change directory to what's is currently stored in Mac clipboard

Using Auth0 with Symfony

Auth0 provide a 3rd party authentication service, as they point out this can have a lot of benefits (along with a few drawbacks). They have written a great tutorial on integrating Auth0 with the PHP Symfony framework here:

https://auth0.com/blog/creating-your-first-symfony-app-and-adding-authentication/

Do many people have experience using Auth0 to handle their authentication? I’ve never used them and am naturally sceptical about tying my platform to a 3rd party supplier I will have to pay. However it’s so frequent seeing a lot of expensive developer time wasted on an inferior inhouse solutions so is this worth a try?

Different versions of shell commands like PHP, Vi – find the true location of Mac/Unix commands, aliases and links

Sometimes it can be a challenge to uncover what terminal command is actually being run on Mac / Unix / Linux systems. Over time, old aliases, links and the repeated installation, upgrading and removal of software can lead to existing and even untouched default commands either unable to be found or running a different version than expected.

Recently we have been using Homebrew to swap in and out multiple versions of PHP (5.4, 5.6, 7.1 etc.) on Macs. Whilst great for quickly testing and developing across versions, this makes it possible to have strange occurrences, like the $ which [command] returning a different version of the software to the one which the shell actually executes!

The following location mismatch demonstrates the problem:

# Problem: Command or Software (in this case php)
# Reported as missing or runs at different location


$ php -v
-bash: /usr/local/bin/php: No such file or directory


$ which php
/usr/bin/php


# WTF ???

Different locations are being referenced by $ which [command]  and the shell.

To fix the discrepancy, use the $ hash [command] to refresh the shell’s command location cache:

# Result before hash command
$ command -v
php /usr/local/bin/php

$ hash php
$

# Result after command
$ command -v php
/usr/bin/php

# Same version recognized everywhere
$ which php
/usr/bin/php

$ php -v
PHP 5.5.36 (cli) (built: May 29 2016 01:07:06)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2015 Zend Technologies

Great, order has returned to the universe and which is again pointing at the correct place. Keep in mind if you do replace (or re-link) the php at /usr/local/bin/php it will be executed instead of the /usr/bin/php, but now all commands should agree on the file’s location.

Debugging Aliases

The above situation can be particularly tricky when dealing with aliases.

If we define an alias and confirm it can be executed, the $ which [alias] and ls commands bizarrely return nothing! Where is the alias going? To find where and what the alias is actually running, utilise the $ type -a [command] command:

# Create alias and watch the confusing behavior
$ alias phpv='php -v'
phpv
PHP 5.5.36 (cli) (built: May 29 2016 01:07:06)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2015 Zend Technologies


$ which phpv
$


$ ls -l phpv
ls: phpv: No such file or directory


# The type command reveals all (-a)
$ type -a phpv
phpv is aliased to `php -v'

Debugging Links

Links act slightly different again. As discovered in this blog post, vi links to vim on a mac, however the which, type -a and command -v commands only shows the link name, not the target:

# These commands give information on links (ls -l is most useful)

$ which vi
/usr/bin/vi

$ type -a vi
vi is /usr/bin/vi

$ command -v vi
/usr/bin/vi

$ ls -l /usr/bin/vi
lrwxr-xr-x 1 root wheel 3 21 Aug 15:29 /usr/bin/vi -> vim

Here we can see that although ls -l was useless for aliases and commands, it is good for showing where links point to.

Although only a summary, these quick commands give a few pointers for when a command either cannot be found or a different version than expected is executing. If you’re still struggling to locate an executed command or know of other handy tips, please leave a comment.

Please share if you find our free website useful, it really helps us produce more tutorials!

Discovering on Mac OS X: vi -> vim

Ok, I admit it, I’ve only just now found out! Seems the vi terminal command on Mac OS X just points to vim anyway and always has done:

$ ls -l /usr/bin/vi
lrwxr-xr-x  1 root  wheel  3  9 Nov  2015 /usr/bin/vi -> vim

I started using a Mac as my main machine for software development in 2009 and have mostly used one since. Given the number of times I have typed a completely redundant m multiplied by the number of years I have been doing it for makes for some frightening numbers.

As a very quick and rough calculation, I made a quick Python doodle estimating how many times I probably opened vim everyday in each year (trying to judge how heavily I might have typed vim per day each year based on role and environment etc.), here here is basic estimation:

Kind of simplistic and assuming:

  1. Approximation of per day opening frequency
  2. Coding 235 full days a year
    (based on: work days + some weekend days + some evenings – holiday days)

This, depressingly, outputs:

237350 seconds

Which is a lot of redundant key strokes! Assuming I type the command at rate of 80 wpm, according to this website this is a kph (keystroke per hour rate) of around 20,000.

This, even more depressingly, equates to :

11.9 hours

The equivalent of a long day wasted …to add to the many I’ve encountered as a Software Developer.

Easily Install Apache Tomcat on Mac OS X El Capitan

Please like or share this article if it helps you. Any problems, ask in comments!

By far the easiest way to install and configure an Apache Tomcat server on a mac is using the open-source homebrew package management suite. If you’re not already using homebrew, check out its popularity on GitHub. It makes open-source package management on mac 100 times cleaner than doing it manually (everything is stored in one place, packages are easy to remove, upgrade and find configs for).

There is a good tutorial here on installing homebrew if you do not already have it.

1)  –  Install Tomcat Server

Install tomcat with the brew install in terminal (as a normal user, not root):

$ brew install tomcat

This will take care of the downloading, installation and configuration of Tomcat and manage its dependencies as well. Take note of the output, brew commands are typically really good at displaying concise but useful info, error messages and help.

Homebrew keeps packages (known as kegs) in the Cellar, where you can check config and data files. It is a directory located at:

$ ls /usr/local/Cellar/

Verify the Tomcat installation using homebrew’s handy “services” utility:

$ brew services list

Tomcat should now be listed here. brew services are really useful for managing system services, type $ brew services --help for more info.

2)  –  Run Tomcat Server

We are going to start the server by executing Tomcat’s Catalina command with the “run” parameter as such:

$ ls /usr/local/Cellar/tomcat/

$ /usr/local/Cellar/tomcat/8.5.3/bin/catalina run

or more generally:

$ /usr/local/Cellar/tomcat/[version]/bin/catalina run

With [version] replaced with your installed version.

The version number and installation directory will have been listed by homebrew at the end of the installation output (typically the last line with a beer symbol in front). Catalina can also be set to start on system launch – although for security reasons we prefer to only run when needed (either using this command or more commonly via an IDE plugin).

Once the server is running you can navigate to the host page at:

http://localhost:8080/

 

3)  –  Configure Tomcat Server

To add and manage applications running on the server you will also need to edit a configuration file:

$ vim /usr/local/Cellar/tomcat/[version]/libexec/conf/tomcat-users.xml

With [version] again replaced with your installed version.

Towards the bottom of this short config file you will see a selection of users – all commented out by default. You need to uncomment one of these and give it the extra role “manager-gui” (preferably also changing the username and password for security). The resultant user entry should look something like this:

<user username="admin" password="password" roles="tomcat,manager-gui" />

After this you can navigate to the page (or click the “Manager App” link on the main Tomcat Server page):

http://localhost:8080/manager/html

Here you can view or delete the included sample application and deploy your own. Usually, it’s easiest to deploy applications in a dev / testing environment using an IDE like PHPStorm or NetBeans however, Tomcat’s web interface is useful also. For reference, deployed applications are usually then located under the directory:

/usr/local/Cellar/tomcat/[version]/libexec/webapps/

 

Please like or share this article if it helps you. Any problems, ask in comments!

Saving a root owned file in vim when not opened using sudo

A very common Linux administration annoyance can be opening a file in vim, making loads of changes, going to save and quit the file (using :wq) only to receive the message:
E45: 'readonly' option is set (add ! to override)
But as only root can write to the file, this won’t work either. Before pulling hair out, try this handy little command:

:wq !sudo tee %