Wordpress has an app. That means there’s an API to normalize communication using a predictable programmatic interface. In this case, as with many others, that’s done using a standard REST interface to communicate. The easiest way to interact with any API is to just read some stuff from the server via curl. You can feed curl the URL to the API by using your URL followed by /wp-json – as follows, assuming a URL of http://www.krypted.com:
curl http://www.krypted.com/wp-json
To view header information:
curl -s -D - http://www.krypted.com -o /dev/null
In the below example we’ll ask for a list of posts by adding /wp/v2/posts to the URL:
curl http://www.krypted.com/wp-json/wp/v2/posts
You’ll see a list of some posts in the output along with a little metadata about the posts. You can then grab an ID and ask for just that post, using a post ID of 48390:
curl http://www.krypted.com/wp-json/wp/v2/posts/48390
You can also see revisions that have been made to a post by appending the URL with /revisions
curl http://www.krypted.com/wp-json/wp/v2/posts/48390/revisions
You can see comments with the comments route:
curl http://www.krypted.com/wp-json/wp/v2/comments
Or pages with the pages route:
curl http://www.krypted.com/wp-json/wp/v2/pages
Or users with the users route:
curl http://www.krypted.com/wp-json/wp/v2/users
Or media that has been uploaded with the media route:
curl http://www.krypted.com/wp-json/wp/v2/media
And the output of each can be constrained to a single item in that route by providing the ID of the item, which shows additional metadata about the specified item. And there are routes for categories, tags, etc.
There’s also some good stuff at https://github.com/WP-API such as https://github.com/WP-API/Basic-Auth which is a plugin that allows you to auth against the API.
curl --user admin:krypted http://www.krypted.com/wp-json/users/me
Not only can you look at user information, you can also add and remove posts. You would add by doing a -X followed by a POST and then feeding a file with the –data option
curl --user admin:password -X POST http://www.krypted.com/wp-json/posts --data @post.json
The output would then include the ID of your new post to wordpress. In the following example, we’ll get rid of the post we were looking at earlier using -X and DELETE in the URL, assuming a username of admin, a password of krypted, and a post ID of 48390:
curl --user admin:krypted -X DELETE http://www.krypted.com/wp-json/posts/48390
If successfully deleted the response would be as follows:

The JSS has the ability to upload multiple .vpptokens, and using those, you can upload separate tokens for sites and then provide App Store apps to different sites based on each having some autonomy by having their own token. This is a pretty cool feature. And using the GUI, you can see when each token expires. You can also see a list of tokens using the API. To see a full list of all the tokens, we’ll just use a basic curl command here:
curl -s -u myuser:mypassword https://kryptedjamf.jamfcloud.com/JSSResource/vppaccounts
This provides an array of output that has the number of tokens in <size> and the id of each along with their name in <id> and <name> respectively, as follows
<?xml version="1.0" encoding="UTF-8"?><vpp_accounts><size>2</size><vpp_account><id>2</id><name>test</name></vpp_account><vpp_account><id>3</id><name>test2</name></vpp_account></vpp_accounts>
Once you know the id of a token, you can pull a bunch of information about that token using the following command:
curl -s -u myuser:mypassword https://kryptedjamf.jamfcloud.com/JSSResource/vppaccounts/id/2
The output would be as follows, with the expiration_date indicated:
<?xml version="1.0" encoding="UTF-8"?><vpp_account><id>2</id><name>test</name><contact/><service_token>xxxxxxxxxxyyyyyyyyyyyzzzzzzzzzaaaaaaaabbbbbbbbbbccccccc</service_token><account_name>krypted</account_name><expiration_date>2017/06/30</expiration_date><country>US</country><apple_id/><site><id>-1</id><name>None</name></site><populate_catalog_from_vpp_content>true</populate_catalog_from_vpp_content><notify_disassociation>true</notify_disassociation></vpp_account>
Or to limit the output to just the expiration date of the token, we’ll use sed to constrain:
curl -s -u myuser:mypassword https://kryptedjamf.jamfcloud.com/JSSResource/vppaccounts/id/2 | sed -n -e 's/.*<expiration_date>\(.*\)<\/expiration_date>.*/\1/p'
The output should just be a standard date, as follows:
2017/06/30
You can then loop through the output of the vppaccounts, build an IFS array, and display the dates for each, listing sites that are about to expire. For anyone that has a lot of sites with individual tokens, this might come in handy. Enjoy.
Hat tip: I thought I’d have to do this using a database query, but it turns out that the field where the stoken is stored contains encrypted data different than the initially encoded base64, which I showed how to decrypt at What’s Really In A VPP Token File from Apple’s VPP?. This is to keep that data private. Instead, hat tip to Christian Dooley, who figured out that this is actually available in the API instead, and therefore I didn’t have to hit the database directly to write this article.

Share:

Do you have a Premium Spotify account? Before you start this, please note that only Premium Spotify accounts can be linked to Amazon Echo.
To link your Spotify account to an Amazon Echo, first open http://alexa.amazon.com and then click on Music & Books. Then, click on Spotify under the Music section.
When prompted, click on “Link your account”
Click Log In To Spotify (unless you don’t have an account, then click “Sign up for Spotify” to setup an account)
I use my Facebook account for Spotify, so I’ll click “Log in with Facebook”
Then, grant access when prompted.
Now, you can say “Alexa, play Halloween mix on Spotify” and you’ll hear this (or I will):

IFTTT makes the possibilities practically endless for what you can do with an Amazon Echo running Alexa. IFTTT provides workflows that connect Alexa to many of the most popular cloud services on the Internet. For example, Alexa can make a spreadsheet of all the songs you listen to using your Prime account, Email you a shopping list, sync To-Dos to Evernote, find your phone, set reminders on your phone, extend Alexa to manage your TV using Harmony, run Wink shortcuts, print files, manage a Wemo bulb (Belkin), control otherwise unsupported thermostats, control items within apps (e.g. make all your Hue lights a given color), time things (e.g. turn on the air conditioning for an hour), lock a door using an otherwise unsupported lock (e.g. with a Smarthings), do random things (e.g. assign a random color to a Hue light), interface with Google Calendar, and so much more.
Basically, if a service can interact with IFTTT using an API, then your Alexa can be made to talk to it. But first, let’s connect your Amazon Echo to IFTTT. To get started, first go to the Alexa channel on IFTTT at Amazon Alexa Channel on IFTTT.
When the page loads, click Connect.
You’ll then be prompted to sign into IFTTT using your Amazon account. Enter your username and password and then click “Sign in using our secure server”.
You’ll then be prompted to trust IFTTT from Amazon. Click Okay.
Then you’ll be able to setup recipes. Let’s say you’d like to put your shopping list on a Slack channel so you can be judged even more harshly than you already are…
Enjoy.

My latest Huffington Post article, Twenty Cool Things You Can Do with Box is online here. It begins:

If you are looking for a secure and uncomplicated and file sharing service, you will find box.com to be a wonderful way to share files from any device. Today, it is easier than ever for businesses to operate globally regardless of how large or small they are. This is because of the digital age that makes works products easy to share or transfer. Here are twenty cool things that you can do with box.com.

Microsoft Azure is Microsoft’s cloud services. Azure can host virtual machines and act as a location to store files. However, Azure can do much more as well, providing an Active Directory instance, provide SQL database access, work with hosted Visual Studio, host web sites or provide BizTalk services. All of these can be managed at https://manage.windowsazure.com.
You can also manage Windows Azure from the command line on Linux, Windows or Mac. To download command line tools, visit http://www.windowsazure.com/en-us/downloads/#cmd-line-tools. Once downloaded, run the package installer.
When the package is finished installing, visit /usr/local/bin where you’ll find the azure binary. Once installed, you’ll need to configure your account from the windowsazure.com site to work with your computer. To do so, log into the windowsazure.com portal.
Once logged in, open Terminal and then use the azure command along with the account option and the download verb:
azure account download
This account downloads the .publishsettings file for the account you’re logged in as in your browser. Once downloaded, run azure with the account option and the import verb, dragging the path to your .publishsettings file from https://manage.windowsazure.com/publishsettings/index?client=xplat:
azure account import /Users/krypted/Downloads/WindowsAzure-credentials.publishsettings
The account import then completes and your user is imported into azure. Once imported, run azure with the account option and then storage list:
azure account storage list
You might not have any storage configured yet, but at this point you should see the following to indicate that the account is working:
info: No storage accounts defined
info: account storage list command OK
You can also run the azure command by itself to see some neat ascii-art (although the azure logo doesn’t really come through in this spiffy cut and paste job):
info: _ _____ _ ___ ___________________
info: /_\ |__ / | | | _ \ __|
info: _ ___ / _ \__/ /| |_| | / _|___ _ _
info: (___ /_/ \_\/___|\___/|_|_\___| _____)
info: (_______ _ _) _ ______ _)_ _
info: (______________ _ ) (___ _ _)
info:
info: Windows Azure: Microsoft's Cloud Platform
info:
info: Tool version 0.7.4
help:
help: Display help for a given command
help: help [options] [command]
help:
help: Open the portal in a browser
help: portal [options]
help:
help: Commands:
help: account to manage your account information and publish settings
help: config Commands to manage your local settings
help: hdinsight Commands to manage your HDInsight accounts
help: mobile Commands to manage your Mobile Services
help: network Commands to manage your Networks
help: sb Commands to manage your Service Bus configuration
help: service Commands to manage your Cloud Services
help: site Commands to manage your Web Sites
help: sql Commands to manage your SQL Server accounts
help: storage Commands to manage your Storage objects
help: vm Commands to manage your Virtual Machines
help:
help: Options:
help: -h, --help output usage information
help: -v, --version output the application version
Provided the account is working, you can then use the account, config, hdinsight, mobile, network, sb, service, site, sql, storage or vm options. Each of these can be invoked along with a -h option to show a help page. For example, to see a help page for service:
azure service -h
You can spin up resources including sites, storage containers and even virtual machines (although you might need to create templates for VMs first). As an example, let’s create a new site using the git template:
azure site create --git
Overall, there are a lot of options available in the azure command line interface. The web interface is very simple, with options in the command line interface mirroring the options in the web interface. Running and therefore scripting around these commands is straight forward. I wrote up some Amazon stuff previously at http://krypted.com/commands/amazon-s3cmd-commands, but the azure controls are really full featured and I’m really becoming a huge fan of the service itself the more I use it (which likely means I’ll post more articles on it soon).

Cumulus comes with a number of commands installed in /usr/local/Cumulus_Workgroup_Server. The assets can be in a shared directory location, such as an NFS mount mapped to /cumulus or /Volumes/Cumulus. But in the /usr/local/Cumulus_Workgroup_Server directory there are a number of commands that can be pretty useful. For example, the stop-admin, stop-cumulus, start-cumulus and start-admin commands can be used to restart the Cumulus using a simple ARD template:
/usr/local/Cumulus_Workgroup_Server/stop-admin.sh
/usr/local/Cumulus_Workgroup_Server/stop-cumulus.sh
sleep 30
/usr/local/Cumulus_Workgroup_Server/start-cumulus.sh
/usr/local/Cumulus_Workgroup_Server/start-admin.sh
There are others, such as status.sh, which shows size of repository, PIDs, and the time running. The repair.sh can be used to repair the database and remove-admin.sh and remove-cumulus.sh can uninstall the admin console and cumulus servers respectively (danger, Will Robinson). The install-admin.sh and install-cumulus.sh scripts can also be used to install these items respectively. The bin directory contains daemons such as cumulusd and services information/cumulusrad.
If you want to work with assets, you’ll probably need the Java SE JDK to run and then query the Tomcat server. This web application environment leverages Cumulus Java classes to provide the API that can then be scripted into various workflows, such as providing a site that queries images in the DAM and displays those matching a given pattern on a website.
Overall, the scripting that can be done without the API is service control oriented, but with the API and a little SOAP you can pretty much grab or change almost anything you need to.

Watchman Monitoring is a tool used to monitor computers. I’ve noticed recently that there’s a lot of traffic on the Watchman Monitoring email list that shows people want a great little (and by little I mean inexpensive from a compute time standpoint) monitoring tool to become a RMM (Remote Management and Monitoring) tool. The difference here is in “Management.” Many of us actually don’t want a monitoring tool to become a management tool unless we are very deliberate about what we do with it. For example, that script that takes a machine name of ‘rm -Rf /’ that some ironic hipster of a user decided to name their hard drive because, well, they can – well that script that was just supposed to run a fix permissions because that ironic jackass of a user in his v-neck with his funny hat and unkempt beard just accidentally cross-site script attacked himself and he’s now crying out of his otherwise brusque no-lense having glasses and you’re now liable for his data loss because you didn’t sanitize that computer name variable before you sent it to some script.
Since we don’t want the scurrilous attention of hipsters everywhere throwing caustic gazes at us, we’ll all continue using a standard patch management system like Casper, Absolute, Munki, FileWave, etc. Many organizations can still take value out of using Watchman Monitoring (and tools like Watchman) to trigger scripted events in their environment.
Now, before I do this I want to make something clear. I’m just showing a very basic thing here. I am assuming that people would build some middleware around something a little more complicated than curl, but given that this is a quick and dirty article, curl’s all I’m using for examples. I’m also not giving up my API key as that would be silly. Therefore, if I were using a script, I’d have two variables in here. The first would be $MACHINEID, the client/computer ID you would see in Watchman. This would be what you see in red here, when looking at an actual computer.
The second variable is my API token. This is a special ID that you are provided from our friends at Watchman. Unless you’re very serious about building some scripts or middleware like right now, rather than bug them for it, give it a little while and it will be available in your portal. I’ve given the token $APITOKEN as my variable there.
The API, like many these days is json. This doesn’t send entire databases or even queries, but instead an expression of each variable. So, to see all of the available variables for our machine ID, we’re going to use curl (I like to add -i to see my headers) and do the following lookup:
curl -i https://318.monitoringclient.com/clients/$MACHINEID.json?auth_token=$APITOKEN
This is going to spit out a bunch of information, parsed with a comma, whereas each variable and then the contents of that variable are stored in quoted text. To delimit my results, I’m simply going to awk for a given position (using comma as my delimiter instead of the default space). In this case, machine name is what I’m after:
curl -i https://318.monitoringclient.com/clients/$MACHINEID.json?auth_token=$APITOKEN | awk -F"," '{ print $4}'
And there you go. It’s that easy. Great work by the Watchman team in making such an easy to use and standards compliant API. Because of how common json is I think integrating a number of other tools with this (kinda’ like the opposite of the Bomgar implementation they already have) is very straight forward and should allow for serious automation for those out there that are asking for it. For example, it would be very easy to say take this output and weaponize it to clear caches before bugging you:

“plugin_id”:1237,”plugin_name”:”Check Root Capacity”,”service_exit_details”:”[2013-07-01] WARNING: 92% (276GB of 297GB) exceeds the 90% usage threshold set on the root volume by about 8 GB.”

Overall, I love it when I have one more toy to play with. You can automatically inject information into asset management systems, trigger events in other systems and if need be, allow the disillusioned youth the ability to erase their own hard drives!

Since the early days, OS X Server has supported performing the serveradmin commands through a web interface. This interface was accessible at the address of the server followed by a colon and then 311 in a web browser. This feature was disabled by default in Mountain Lion. But fear causes hesitation, and hesitation will cause your worst fears to come true, so we’re going to turn it back on. To enable, use the following command:
sudo defaults write /Library/Preferences/com.apple.servermgrd requireUserAgent -bool false
Once done, open https://127.0.0.1:311 in a web browser, or replace 127.0.0.1 with the address of the server if accessing from another location. This is stimulating, but we’re out of here. So, authenticate to be greeted with a list of services.

Lawyers don’t surf.

At the Server Admin Modules page, each service output from `serveradmin list` appears. Clicking each produces the ability to run the commands you can supply using `serveradmin command` along with the service name. For example, to get a list of all of the connected AFP users in OS X Mountain Lion Server, run the following command:
sudo serveradmin command afp:command = getConnectedUsers
Now, to get the same list, click on the servermgr_afp.html link and then click on getConnectedUsers.

Life sure has a sick sense of humor, doesn’t it?

Click on Send Command to see the output.

Peace, through superior firepower.

You then see an XML output that shows who’s connected (since I’m on a flight right now, luckily no one is connected to mine). Now you also have a URL in the toolbar, which should look something like this:

Rad, unicode. I guess spaces aren’t really compliant in URLs. Before we look at that, let’s take a look at what we can do with these. If you follow what I write, you have probably noticed that I use curl for tinkering with URLs a lot. In many cases, this is not the right tool. But I usually start there and move on if need be. Six seconds. We’re going to be meat waffles.
Because we’re going to assume the server is using a self-signed cert that we don’t yet trust, we’re gonna’ use a -k along with curl. Then we’re going to follow that with the link. However, since we need to auth, we’re going to also go ahead and embed the username (in this case johhny) followed by a : and then the password (in this example, bodhi), followed by an @ in between the https:// and the server address, as follows:
curl -k https://johhny:bodhi@127.0.0.1:311/commands/servermgr_afp?input=%3C%3Fxml+version%3D%221.0%22+encoding%3D%22UTF-8%22%3F%3E%0D%0A%3Cplist+version%3D%220.9%22%3E%0D%0A%3Cdict%3E%0D%0A%09%3Ckey%3Ecommand%3C%2Fkey%3E%0D%0A%09%3Cstring%3EgetConnectedUsers%3C%2Fstring%3E%0D%0A%3C%2Fdict%3E%0D%0A%3C%2Fplist%3E%0D%0A&send=Send+Command
The output includes the afp:usersArray which shows active connections. The most interesting options, other than those for services you run in your environment, ar those under servermgr_info. Here, you can get PIDs for processes, kill PIDs, view logs, check file sizes, delete data and even reboot servers. Overall, this option has some security concerns, but provides some good insight into how the Server Admin tool worked under the hood in Mac OS X Lion Server and below while also serving as a functional option as an API for the product, especially given that output is in XML, similar to the output of most other modern APIs.
Vaya con Dios, Brah.