Spring updates for Zentral
We continuously update the Zentral codebase, recently we’ve merged our latest dev branch into master. Why worth mention with a full blogpost ? — Well we’ve build-in some nice new updates into Zentral and so you’ll probably want to check these out in more detail. Let’s start a quick overview on latest enhancements and dive a bit into our reorganized inventory view and a new introduced “drilldown” functionality.
Ok, so what’s new ?
Functionality and Code updates
This is a list of noteworthy additions that we’d like to emphasis for our spring release of Zentral:
- A reorganized inventory view with a new drilldown user-interface (UI)
- Based on drilldown you’ll now find a inventory_export file .xlsx option
- SAML 2.0 enhancements address minor issues seen with AzureAD and SingleSignOn(SSO) setup
- The current zentral-all-in-one builds now all include latest versions of ElasticStack 6.7 and Prometheus 2.8
- Kibana 6.7 — automatically sets index pattern ‘zentral-events’ as default
- Upgrade to Django v2.1
The latest code can be pulled from GitHub for existing Zentral setups. If you’re running a zentral-all-in-one deployment use the build-in update tool (ensure you have Python 3.5 installed as Django 2.1 requirement). If you happen to start over with a deployment from scratch, follow the guides to create a new instance on AWS or GCP. For both platforms we’ve build new images with packer and all components embedded (see notes below on build timestamps ).
New Drilldown Inventory
The most obvious change is our reorganized Inventory view now that provides enhanced search and drilldown capability. As before Inventory > Machines is a representation of all machines (aka devices or endpoints) that Zentral aggregates from inventory sources. Our smart filtering is now at hand for much faster inventory searches. With just few clicks one can drilldown to match a filter criteria and in turn a list of machines quickly reduce and shows only those correlate to the applied filtering. In our prod environment this works astonishingly fast with hundreds of machine entries in our inventory.
Ok sounds nice, but what’s inventory sources again ?
Recap Inventory Sources
As before in Inventory > Machine view you’ll see all machines (devices or endpoints) here that are linked to one or many inventory sources. Zentral can simultaneously connect and aggregate inventory information from many sources in parallel. This could be few Jamf Pro Servers (on-prem testing, on-prem production, JamfCloud instance, etc.) and/or FileWave along with Osquery, Munki, Watchman Monitoring and Google Santa. A single machine can happen to be a member of more than one inventory source and now with drilldown you’ll much quicker navigate across and also precisely locate machines thru filtering from the overall centralized inventory.
Drilldown — Inventory filtering
The drilldown in new Inventory > Machine view works with a simple click to add or remove a filter and reduce into specific areas. Probably a gif is worth a thousand words here— you can see a short inventory drilldown demo below:
Drilldown — Application filter
Now what about some currently hidden details from your inventory? It would be great to have a similar filter capability to separate specific macOS application versions, display count per version and drill into what is installed where across the fleet. Yes for just this purpose we provide a neat option to “Add a drill down filter” — you can add a filtering on App information the default Inventory > Machines view is extended for that. The a majority of inventory sources (Osquery, Munki, FileWave, etc.) you go and insert a valid BundleID (i.e. org.mozilla.Firefox), for Jamf Pro the inventory for apps is reported a bit differently. With Jamf App info you’ll must provide a valid AppName.app to apply same filtering. Of course the drill down works for both in identical way. This application filtering and drill down becomes pretty useful for our inventory_export and reporting functionality explained later.
Here’s a gif to see this in action:
Drilldown — edit the filter view
Ok so you can add items but to remove the ones you don’t want to see for the moment? In a inventory view you can remove a filter item very quickly.
Again a gif to see this in action:
Restore custom views
Ok so how to store a custom build view? For this we’ve setup a link scheme as the option to store and return to a custom view. The core idea here is everyone knows how to store a link and/or create a bookmark in a browser. Now with a simple link scheme you can quickly re-creates a custom view and use drilldown anytime, it just requires a bookmark. Otherwise the default view is quickly editable anytime.
The resulting link scheme with an URL to store looks similar to this:
WYSIWYG Reporting and Export
What you see is what you get and this apply inventory reporting and exporting data. This is nice feature becomes quickly versatile in case you need to run ad hoc or even a recurring inventory report from the inventory sources. With the custom filtering options you can run a inventory_export anytime just with click on the XLSX button. Next moment you’ll see a report file that downloads a file with name and timestamp similar to this one: inventory_export_2019–03–27_10–51–16.xlsx
Combined with the extra filtering (i.e. apps ) you perform a simple sequence and generate detailed inventory reports when needed. The exported data is ready to process further and can visualized the inventory report with other tools (such as Excel, Numbers, Tableau, MS PowerBI, Google DataStudio, etc. ).
- Store a link with your current inventory view and filter set
- Open the link in another browser window (to validate)
- Press the XLSX download button
- You’ll see a report file with a name and timestamp like inventory_export_2019–03–27_10–51–16.xlsx
- Repeat steps 2–4 next time to fetch a new inventory_export
In the gif you’ll see an inventory_export assembled from a WYSIWYG view downloaded as a .xlsx file with a timestamp. Of course such file is ready for post processing, stay tuned for more on that.
We will catch up on this topic for more “report and processing” on inventory in one of our future blogposts.
Elastic Stack 6.7
You can read all the buzz here:
Version 6.7 of the Elastic Stack is here, and oh what a release it is. We're not sure if Christmas came early, late, or…www.elastic.co
We have build ElasticStack 6.7 into the core of Zentral and while Kibana 6.7 needs some RAM to breath (hint: not fun in a EC2 t2.micro) it’s fun to work with all new features in Kibana.
Of course all zentral-all-in-one images that we’ve pre-build for cloud deployment start up with ElasticStack 6.7 out of the box.
Let’s wrap up with valuable information in case you start run a new deployment of zentral-all-in-one on AWS or GCP. Below you see a summary with updated information and reference for a deployment hick-up seen with GCP.
New AWS AMI images (available for deployment)
The new zentral-all-in-one AMIs have been created and are available — the following AMI IDs are our latest ones (per region):
- eu-central-1: ami-0b5857da66e223509
- us-east-1: ami-0a5c429add7cf8d16
- us-west-2: ami-0d12d51a844d1632e
Detailed steps and procedure for a AWS deployment have not changed.
New GCP Image (available for deployment)
We also created a new image for Google Cloud Platform (GCP) as well. But when you’re following the deployment instructions for GCP (as to be found in our former blog posts here) you’ll likely run into an API error like this:
ERROR: (gcloud.compute.images.create) Could not fetch resource:
- The resource 'https://www.googleapis.com/storage/v1/b/zentralopensource/o/zentral-all-in-one.tar.gz' of type 'Google Cloud Storage object' was not found.
A quick fix procedure with a manual download of the artifact instead of API based has been described by a fellow Zentral user Thunderbear — you can read up the steps right here:
ERROR: (gcloud.compute.images.create) Could not fetch resource:
— The resource…medium.com
We will refine our original install guide for GCP soon. For the moment we wait on another response from our GCP Support contact. The API error doesn’t throw in a GCP account that “owns” a public artifact. Since few weeks it suddenly happens if called from a separated accounts.This is related to permissions and under the hood changes on how the gcloud CLI tool connects with a public available GCP bucket with the API.
See below hard to figure what set of perms more than a full ‘public’ access can be set for a bucket artifact.
Our latest of zentral-all-in-one.tar.gz (created 3/27/19, 11:10:55 PM UTC+1) build for GCP can be downloaded as a public available item here:
There’s one more thing to share
We’ve launched our new company Zentral Pro Services GmbH & Co. KG just a few weeks back in February 2019. Under our new brand we focus to operate as a specialized professional services company. We do provide our expertise and services on open source technology and consult on common cloud and IdP solutions. We also work as Jamf Integrators and Jamf Professional Services Partner.
As before within our former company our main scope is to employ detailed expertise and help clients to manage the Apple platform and go beyond. We do research and development for a living.
Of course our continued work on Zentral as open source is a vital element in our business — it’s a core element and great platform for our ongoing research and development (R&D) work.
If you feel a need to reach out to get us involved with your future project, if you look for certain expertise or external R&D capacity to help realize and shape workflows in your environment. We’re available to contact on the usual channels — via Email (see weblink below), your trusted Jamf Buddy, or ping us directly on Macadmins Slack.