Ubuntu Patch Management with Tanium

I have more than a dozen Ubuntu servers that perform various jobs.  Some of these systems are considered “production” and keeping the installed packages up to date is extremely important.  For this article I want to discuss how I am upgrading the installed packages on these systems using the Apt-Get utility and the Tanium platform.

I have built a collection of content that was published on the Tanium Community website.  This solution includes multiple sensors, packages and other types of content called Ubuntu Package Management.

Download and Import Content

Visit https://community.tanium.com/repo/solution/192 and click the “Download” button after logging into the Tanium Community website.

Log into your development infrastructures Tanium Console, then browse to Authoring->Import Content, select the downloaded XML file to complete the import process.  It is safe to overwrite any existing sensors as the only one I am using that is not original content is the Operating System sensor.


Dashboard Tour

Now we move onto actually using this content and keeping the packages on your Ubuntu systems updated.   On the “Home” tab of your Tanium Console, you’ll find a new dashboard link appear under the “Other Dashboards” block.


A few saved questions will appear… the left pane shows all packages within your environment that have available updates.  The right pane will list all of the Ubuntu computers you have within your environment.


Available Actions

There are currently two available packages/actions included with the solution pack.  The first is accessible by right clicking on one or more of your Ubuntu systems in the right pane and the default action is Reboot Ubuntu Machine.


The second action is closely tied to the Ubuntu Available Patches sensor as it takes the selected result of that sensor to launch the action.  Thus in the left pane, right click on one of the packages and Upgrade Available Ubuntu Package.


There are other handy actions you can take.  Right clicking on one of the computers, you can drill down into the Ubuntu Available Patches and a list of packages for that one system will appear…Then you can deploy or upgrade a single package from there.  Further right clicking on the computer provides you with the ability to Upgrade All Ubuntu Packages, if that is preferable.

Setting up Scheduled Actions

The Tanium Community site does not allow for the sharing of Saved Actions on purpose.  Thus these must be setup manually.  The first one I’d like to setup is to download the available package updates definitions on a daily basis.  Since most of my systems are online 24×7, having this action run at least once a day is perfect.  To accomplish this, ask the following Tanium question:

Get Is Ubuntu from all machines

It uses the Is Ubuntu sensor which returns one of two answers for your entire infrastructure… True or False.  Right click on the True and deploy the Update Ubuntu Package Definitions package.


I would like this action to occur daily on all of my Ubuntu computers… thus I will be setting up a scheduled action.  I have decided to have the action run between 4am and 5am daily so when I start working and want to check my package status, I have the latest data.


Please note that the Action Group is “Ubuntu”.  This is because I have setup an action group that only includes my Ubuntu systems that I’ve targeted with my “Ubuntu Computers” computer group.



Using the Tanium platform to manage your enterprise is extremely easy.  With a little bit of work and understanding you can put together a solution to accomplish nearly anything you want.

Tanium Client Deployment Tool

I have recently stood up a half-dozen virtual servers in a new home lab I am building to compliment my home office.  This means I want to get the Tanium Client installed onto these endpoints.  Rather than do it manually, I’m choosing to use the Tanium Client Deployment Tool and install them remotely from my windows workstation.  At the time of this writing v5.0.0.6 was the latest and has a few essential features required for installing the agent onto my new non-windows systems.

Installing the Tool

Installation of the Client Deployment Tool is relatively straightforward.  Launch the installer and click “Install”.  Assuming the default installation directory is acceptable.




Initial Tool Setup

Once you launch the tool there are a few things that need to happen.  The first is the tool itself will prompt you to download the very latest agents for the various OS platform Tanium supports.  Allow that to happen…



Next we will need to point the tool at our server infrastructure in two ways… First by pointing the utility at our tanium.pub file.  This file can be found in the Tanium Server root folder on the server.  Second we’ll need to specify the hostname or IP address of the server we will be pointing endpoints at.  This second value could be the hostname or IP address of a zone server or even an alias that functions differently inside and outside your network.  Lastly if you chose to use a port number other than the default 17472, you’ll need to specify that now.

Install the Agent

For this article we will deploy the Tanium Agent to one of my new Ubuntu 14.04 LTS virtual servers.  My user account on that box has sudo permissions and that is required in order to install new software.


Next we will specify a single endpoint to deploy too.  To do that we change the lower-left tabs to “Computer List” and type in the hostname of the targeted endpoint.  Then change the very bottom left dropdown to “Linux_Mac_Only” to avoid unnecessary timeouts by trying a windows connection and hit the “Analyze” button.


If all works well our tool will report back “Client not installed”.  Select that row and click “Install”. 


All done… The client deployment was successful.  To validate, we can simply log into the Tanium Console and check Administration->System Status to see our new endpoint listed and reporting in.


In Conclusion

The Client Deployment Tool is a great utility for getting the Tanium Agent installed on your endpoints fast.

CRITs use of MongoDB and starting automatically on Ubuntu

I recently was playing around with CRITs and followed their installation instructions closely (VERY HARD).  They could use some better install scripts to make things smoothly, but what do you expect from a community project.

Anyways, I see in their documentation when it gets to the MongoDB section how to start it at the command line.  Getting past that worked well… but i’m wanting to setup a production style instance which requires the database to start automatically on startup.  Apache (which runs the CRITs UI starts automaticaly by default) but their instance of MongoDB does not.  So i submitted a ticket… which quickly got squashed as “not their problem”.  While I agree this is not their problem, they do want people to use their product, right?  A few bits of documentation on here’s a link to starting MongoDB automatically would have been helpful.  Well… I submit this as that link…

Create /etc/init.d/mongodb with the following info:


# Provides:          mongodb
# Required-Start:    $remote_fs $syslog
# Required-Stop:     $remote_fs $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: MongoDB

# Change the next 3 lines to suit where you install your script and what you want to call it

# Add any command line options for your daemon here
DAEMON_OPTS="--fork --logpath /var/log/mongodb.log --logappend --nohttpinterface"

# This next line determines what user the script runs as.
# Root generally not recommended but necessary if you are using the Raspberry Pi GPIO from Python.

# The process ID of the script when it runs is stored here:

. /lib/lsb/init-functions

do_start () {
    log_daemon_msg "Starting system $DAEMON_NAME daemon"
    echo 0 > /proc/sys/vm/zone_reclaim_mode
    start-stop-daemon --start --background --pidfile $PIDFILE --make-pidfile --user $DAEMON_USER --chuid $DAEMON_USER --startas $DAEMON -- $DAEMON_OPTS
    log_end_msg $?
do_stop () {
    log_daemon_msg "Stopping system $DAEMON_NAME daemon"
    start-stop-daemon --stop --pidfile $PIDFILE --retry 10
    log_end_msg $?

case "$1" in



        status_of_proc "$DAEMON_NAME" "$DAEMON" && exit 0 || exit $?
        echo "Usage: /etc/init.d/$DAEMON_NAME {start|stop|restart|status}"
        exit 1

exit 0

Change /etc/init.d/mongodb to executable:

sudo chmod +x /etc/init.d/mongodb

and configure it for startup:

sudo update-rc.d mongodb defaults

Now your MongoDB instance that is spoken to in the CRITs documentation will start automatically on boot.