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:
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:
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:
You can also see revisions that have been made to a post by appending the URL with /revisions
You can see comments with the comments route:
Or pages with the pages route:
Or users with the users route:
Or media that has been uploaded with the media route:
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.
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:
To dig in deeper, check out http://v2.wp-api.org/reference/posts/ where the whole schema is documented. You can also use the https://github.com/WP-API GitHub site to access a command called wp (as well as PHP, node, and java clients) that can be run at the command line for simple scripting interfaces. This could allow you to, for example, simply backup posts to json files, etc.
Also, it’s worth noting that various plugins will require their own interface (note there’s no themes or plugins route), such as woocommerce, interfacing with http://gerhardpotgieter.com/2014/02/10/woocommerce-rest-api-client-library/ or https://woocommerce.github.io/woocommerce-rest-api-docs/.
krypted July 14th, 2017
Posted In: WordPress
When you’re regression testing, you frequently just don’t want any delays for scripts unless you intentionally sleep your scripts. By default Safari has an internal delay that I’d totally forgotten about. So if your GUI scripts (yes, I know, yuck) are taking too long to run, check this out and see if it helps:
defaults write com.apple.Safari WebKitInitialTimedLayoutDelay 0
With a script I was recently working on, this made the thing take about an hour less. Might help for your stuffs, might not.
If not, to undo:
defaults delete com.apple.Safari WebKitInitialTimedLayoutDelay
krypted February 1st, 2017
Dropping network connections can be incredibly frustrating. And finding the source can be a challenge. Over the years, I’ve found a number of troubleshooting methods, but the intermittent drop can be the worse to troubleshoot around. When this happens, I’ve occasionally resorted to scripting around failures, and dumping information into a log file to find the issue. For example, you may find that when a network connection fails, you have a very strong signal somewhere, or that you have a very weak signal on all networks.
I’ve found there are three pretty simple commands to test joining/unjoining, and using networks (beyond the standard pings or port scans on hosts). The first is the airport command, along with –disassociate. This just unjoins all networks:
sudo /System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/airport --disassociate
The second is a quick scan. Here, I’ve grep’d out the network I’m after (aka SSIDofNetwork – a very likely wireless network name), but when looking for environmental issues, you might choose to parse this into a csv and output all networks:
sudo /System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/airport -s | grep SSIDofNetwork
Finally, you can join a network. You might have to escape out special characters in a password and it’s never wise to put a password into a script, etc. But, quick and dirty, this will join that SSIDofNetwork network:
sudo networksetup -setairportnetwork en0 "SSIDofNetwork" mysecretpassword
Anyway, loop it, invoke it however you invoke it, etc. Hope this helps someone, and if you have other tricks you’ve found helpful, feel free to throw them in the ‘ole comments!
krypted August 26th, 2016
Posted a new swift command line tool to accept serial number data from an Apple device and respond with warranty information about a device at https://github.com/krypted/swiftwarrantylookup. This is based on pyMacWarranty, at https://github.com/pudquick/pyMacWarranty.
krypted March 16th, 2016
One of the options thats a tad bit hidden in OS X is the Secure Erase option, which runs a multi-pass erase on a volume. Additionally, there’s no option to Secure Erase free space on a volume. But you can still securely erase whatever you’d like (other than you boot volume obviously), when needed. To do so, use the diskutil command along with the secureErase option.
The format of the command to secureErase freespace is:
diskutil secureErase freespace [level] [device]
The levels are as follows (per the man page as not all of these are specified in Disk Utility):
So for example, let’s say you had a volume called Seldon and you wanted to do a standard Single-pass zero-fill erase. In this example you would use the following:
diskutil secureErase freespace 0 /Volumes/Seldon
If you were to automate the command then you would want to dump the output into a log file. For example:
diskutil secureErase freespace 0 /Volumes/Seldon > /var/log/secureeraselog.tmp
You can also secureErase a volume itself. To erase a volume called /Volumes/Seldon, use the same structure of the command, but this time without the freespace option:
diskutil secureErase 0 /Volumes/Seldon
The latest update to Disk Utility removes a lot of options from the GUI, but overall, I have yet to find a scenario where a task I need to perform isn’t still available, if only from the command line.
krypted January 7th, 2016
Pretty much every script I’m working on these days must be run as root. Checking what user is running something is pretty straight forward, as there’s a built-in shell variable for $USER that contains the user running a script. To see this real quick, simply run the following:
You can then put this into your scripts. I’ve been using the same block of code for decades, which can be run in a script by itself if you’d like to paste this into one.
if [[ $USER != "root" ]]; then
echo "This script must be run as root"
echo "You are root"
Note: Keep in mind that the built-in $USER variable is case sensitive.
Obviously, most people won’t keep the lines that contain the else and you are root echo statements. You can just remove these or replace them with the meat of your script that requires elevated privileges to run. Enjoy.
krypted December 21st, 2015
Someone hands you a USB drive. You put it in your computer and you can’t access anything on it. You are running an imaging lab and you want to backup or troubleshoot a device before you re-image it, but you can’t access certain files. Obviously, you can sudo. But, you can also simply disable permissions on that volume (which, like getting someone to make you a sandwich, requires sudo of course).
The command used to enable and disable permissions on a volume is vsdbutil, located at /usr/sbin/vsdbutil. And there’s a LaunchDaemon at /System/Library/LaunchDaemons/com.apple.vsdbutil.plist that interacts with diskarbitrationd so that when a volume is mounted, it is marked as having permissions activated or deactivated (which is basically “Ignore Permissions” at the Finder).
To use vsdbutil to enable “Ignore Permissions”, use the -d flag followed by the path to the volume:
sudo /usr/sbin/vsdbutil -d /Volumes/Myvolume
To then enable (or activate, thus the a) permissions again, use the -a flag:
sudo /usr/sbin/vsdbutil -a /Volumes/Myvolume
You can also run the -c to see the status for a given path:
sudo /usr/sbin/vsdbutil -c /Volumes/Myvolume
And last but certainly not least if you’re working on a lot of volumes, the -i option will enable permissions on all mounted HFS and HFS+ volumes:
sudo /usr/sbin/vsdbutil -i
Overall, it’s very easy to send these commands using a positional parameter (e.g. $1) to a script, performing a mount, some operation (backup, reimage, restore, repair some corrupted data, etc).
Note: You can’t Ignore Permissions of FAT or FAT32 volumes using the command line or a Finder Get Info screen.
krypted December 1st, 2015
The hostinfo command displays information about your host; namely your kernel version, the number of processors the kernel is configured for, the number of physical processors active, the number of logical processors active, the type of those processors, which ones are active, the amount of memory available, tasks, threads, and average load.
Run hosting without any arguments or options:
The output would be as follows (ymmv per system):
Mach kernel version:
Darwin Kernel Version 15.0.0: Wed Aug 26 19:41:34 PDT 2015; root:xnu-3247.1.106~5/RELEASE_X86_64
Kernel configured for up to 4 processors.
2 processors are physically available.
4 processors are logically available.
Processor type: x86_64h (Intel x86-64h Haswell)
Processors active: 0 1 2 3
Primary memory available: 16.00 gigabytes
Default processor set: 395 tasks, 1711 threads, 4 processors
Load average: 1.78, Mach factor: 2.21
There are a bunch of other commands that can provide far more detailed information about your system. However, hostinfo has remained basically unchanged for 13 years, so if I can get something there, I can trust it’s fairly future-proofed in my scripts.
krypted November 23rd, 2015
Posted In: Mac OS X
Encrypting a volume in OS X couldn’t be easier. In this article, we will look at three ways to encrypt OS X El Capitan volumes in OS X Server 5. The reason there are three ways is that booted volumes and non-booted volumes have different methods for enabling encryption.
Encrypting Attached Storage
For non-boot volumes, just control-click or right-click on them and then click on Encrypt “VOLUMENAME” where the name of the volume is in quotes.
When prompted, provide an encryption password for the volume, verify that password and if you so choose, provide a hint.
Once the encryption process has begun, the entry previously clicked on says Encrypting “VOLUMENAME” where the name of the volume is in quotes.
Before you can encrypt a volume from the command line you must first convert it to CoreStorage if it isn’t already. As volumes on external disks aren’t likely to be CoreStorage, let’s check using diskutil along with corestorage and then list:
diskutil corestorage list
Assuming your volume was already formatted with a non-corestorage format and isn’t listed, locate the volume and document the disk identifier (in this case disk2s3). Then, run diskutil corestorage along with the convert verb and the disk, as follows (no need to run this command if it’s already listed):
sudo diskutil corestorage convert disk2s3
The output should look similar to the following:
Started CoreStorage operation on disk2s3 Reco Resizing disk to fit Core Storage headers Creating Core Storage Logical Volume Group Attempting to unmount disk2s3 Switching disk2s3 to Core Storage Waiting for Logical Volume to appear Mounting Logical Volume Core Storage LVG UUID: 19D34AAA-498A-44FC-99A5-3E719D3DB6FB Core Storage PV UUID: 2639E13A-250D-4510-889A-3EEB3B7F065C Core Storage LV UUID: 4CC5881F-88B3-42DD-B540-24AA63952E31 Core Storage disk: disk4 Finished CoreStorage operation on disk2s3 Reco
Once converted, the LV UUID (LV is short for Logical Volume) can be used to encrypt the logical volume using a password of crowbar to unlock it:
sudo diskutil corestorage encryptvolume 4CC5881F-88B3-42DD-B540-24AA63952E31 -passphrase crowbar
The output is similar to the following:
Started CoreStorage operation on disk4 Reco
Scheduling encryption of Core Storage Logical Volume
Core Storage LV UUID: 4CC5881F-88B3-42DD-B540-24AA63952E31
Finished CoreStorage operation on disk4 Reco
According to the size, this process can take some time. Monitor the progress using the corestorage list option:
diskutil corestorage list
In all of these commands, replace core storage w/ cs for less typing. I’ll use the shortened version as I go. I know that we rarely change passwords, but sometimes it needs to happen. If it needs to happen on a core storage encrypted volume, this can be done from the command line or a script. To do so, use diskutil cs with the changevolumepassphrase option. We’ll use -oldpassphrase to provide the old password and -newpassphrase to provide the new passphrase.
diskutil cs changeVolumePassphrase FC6D57CD-15FC-4A9A-B9D7-F7CF26312E00 -oldpassphrase crowbar -newpassphrase hedeservedit
I continue to get prompted when I send the -newpassphrase, so I’ve taken to using stdin , using -stdinpassphrase. Once encrypted there will occasionally come a time for decrypting, or removing the encryption, from a volume. It’s worth noting that neither encrypting or decrypting requires erasing. To decrypt, use the decryptVolume verb, again with the -passphrase option:
diskutil cs decryptvolume 4CC5881F-88B3-42DD-B540-24AA63952E31 -passphrase crowbar
FileVault 2: Encrypting Boot Volumes
Boot volumes are configured a bit differently. This is namely because the boot volume requires FileVault 2, which unifies usernames and passwords with the encryption so that users enter one username and password rather than unlocking drives. To configure FileVault 2, open the Security & Privacy System Preference pane and then click on the FileVault tab. Click on the lock to make changes and then provide the password for an administrative account of the system. Then, click on “Turn On FileVault…”
You’ll then be prompted to restart; do so to begin the encryption process.
When prompted, choose whether to create a key or save the key to iCloud. In most cases, on a server, you’ll want to create a recovery key and save it to a very safe place.
When prompted with the Recovery Key, document it and then click on Continue. Choose whether to restore the recovery key with Apple. If you will be storing the key with Apple then provide the AppleID. Otherwise, simply click the bullet for “Do not store the recovery key with Apple” and then click on the Continue button.
When prompted, click on Restart to reboot and be prompted for the first account that can unlock the FileVaulted system.
Once encrypted, the FileVault tab in the Security & Privacy System Preference pane shows the encryption status, or percent during encryption.
That’s it. Managing FileVault 2 using the System Preferences is about as easy as it can get. But for those who require mass management, Apple has provided a tool called fdesetup for that as well.
Using fdesetup with FileVault 2
FileVault 2 now comes with a nifty configuration utility called fdesetup. To use fdesetup to encrypt the boot volume, first check FileVault’s status by entering the fdesetup command along with the –status option (wait, no — required any more!):
As with most other commands, read the help page before starting to use just in case there are any changes to it between the writing of this article and when you kick off your automated encryption. Done using the help verb:
After confirming FileVault is off, enable FileVault with the enable option, as follows:
sudo fdesetup enable
Unless additional parameters are specified, an interactive session prompts for the primary user’s short name and password. Once enabled, a Recovery key is returned by the fdesetup command. You can also cancel this by just hitting Control-C so we can look at more complicated iterations of the command. It should be recorded or otherwise stored, something easily done by mounting in a script (e.g. a write-only share in a script for key escrowing). If more complicated measures are needed, of course check out Cauliflower Vest at code.google.com. The fdesetup command is now at version 2.36:
Now, if you run fdesetup and you’ve deployed a master keychain then you’re going to have a little more work to do; namely point the -keychain command at the actual keychain. For example:
sudo fdesetup enable -keychain /Library/Keychains/FileVaultMaster.keychain
To define a certificate:
sudo fdesetup enable -certificate /temp/filename.cer
Adding additional users other than the one who enabled fdesetup is a bit different than the first:
sudo fdesetup add -usertoadd robin
To remove users, just remove them with a remove verb followed by the -user option and the username:
sudo fdesetup remove -user robin
The remove and add options also offer using the -uuid rather than the username. Let’s look at Robin’s uid :
dscl . read /Users/robin GeneratedUID | cut -c 15-50
Yes, I used cut. If you have a problem with that then take your judgmental fuc… Nevermind. Take that GUID and plug it in as the uuid using the -uuid option. For example, to do so with the remove verb:
sudo fdesetup remove -uuid 31E609D5-39CF-4A42-9F24-CFA2B36F5532
Or for good measure, we can basically replicate -user w/ -uuid for a nice stupid human trick:
sudo fdesetup remove -uuid `dscl . read /Users/robin GeneratedUID | cut -c 15-50`
All of the fdesetup commands can be run interactively or using options to define the variables otherwise provided in the interactive prompt. These are defined well in the man page. Finally, let’s look at -defer. Using -defer, you can run the fdesetup tool at the next login, write the key to a plist and then grab it with a script of some sort later.
sudo fdesetup enable -defer /temp/fdesetupescrow.plist
Or define users concurrently (continuing to use the robin test user):
sudo fdesetup enable -user robin -defer /temp/fdesetupescrow.plist
FileVault accounts can also use accounts from Directory Services automatically. These need to synchronize with the Directory Service routinely as data is cached. To do so:
sudo fdesetup sync
This is really just scratching the surface of what you can do with fdesetup. The definitive source for which is the man page as well as a nicely done article by Rich Trouton.
Encrypting Time Machine Backups
The last full disk encryption to discuss is Time Machine. To encrypt Time Machine backups, use Time Machine’s System Preference pane. The reason for this being that doing so automatically maintains mounting information in the Operating System, rather than potentially having an encrypted drive’s password get lost or not entered and therefore not have backups run.
To enable disk encryption for Time Machine destinations, open the Time Machine System Preference pane and click on Select Backup Disk… From the backup disk selection screen, choose your backup target and then check the box for “Encrypt backups”. Then, click on Use Disk.
At the overlay screen, provide a backup password twice and if you would like, a hint as to what that password is. When you are satisfied with your passwords, click on the Encrypt Disk button.
Now, there are a couple of things to know here. 1. Don’t forget that password. 2. If you use an institutional FileVault Key then still don’t forget that password as it will not work. 3. Don’t forget that password…
Scripty CLI Stuff
We’ve always been able to enable FileVault using scripts thanks to fdesetup but now Apple’s taken some of the difficulty out of configuring recovery keys. This comes in the form of the changerecovery, haspersonalrecoverykey, hasinstitutionalkey, usingrecoverykey and validate recovery options. These options all revolve around one idea: make it easier to deploy centrally managed keys that can be used to unlock encrypted volumes in the event that such an action is required. There’s also a -recoverykey option, which indicates the number of the key if a recovery key is being used.
To use the fdesetup command to check whether a computer has a personal recovery key use the haspersonalrecoverykey verb, as follows:
The output will be a simple true or false exit. To use the fdesetup command to check whether a computer has an institutional recovery key, use the hasinstitutionalrecoverykey verb, as follows:
To enable a specific personal recovery key, provide it using the changerecovery verb, as follows:
fdesetup changerecovery -personal
This is an interactive command, so when prompted, provide the appropriate personal key. The removerecovery verb can also be used to remove keys. And my favorite, validaterecovery is used to check on whether or not a recovery key will work to unlock a host; which can be tied into something like an extension attribute in Casper in order to store a key and then validate the key every week or 4. This helps to make sure that systems are manageable if something happens.
The enable verb also has a new -authrestart which does an authenticated reboot after enabling FileVault. Before using the -authrestart option, check that a system can actually run it by using fdesetup with the supportsauthrestart verb and it will exit on true or false.
Defer mode is nothing new, where FileVault waits until a user password is provided; however, a new verb is available called showdeferralinfo which shows information about deferral mode. This is most helpful as a sanity check so you don’t go running commands you already ran or doing things to systems that have already been provided with tasks to perform otherwise.
Encrypting data in OS X can take on other forms as well. The keychains encrypt passwords and other objects. Additionally, you can still create encrypted dmgs and many file types have built in encryption as well. But the gist is that Apple encrypts a lot. They also sandbox a lot and with the addition of gatekeeper are code signing a lot. But encrypting volumes and disks is mostly about physical security, which these types of encryption provide a substantial solution for.
While all this security might seem like a lot, it’s been in Apple’s DNA for a long time and really security is about layers and the Mac Systems Administrator batbelt needs a lot of items to allow us to adapt to the changing landscape of security threats. OS X is becoming a little more like iOS as can be expected and so I would suspect that encryption will become more and more transparent as time goes on. Overall, the options allow encrypting every piece of data that goes anywhere near a system. The mechanisms with which data is now encrypted are secure, as is the data at rest. Once data is decrypted, features like Gatekeeper and the application layer firewall supplement traditional network encryption to keep well secured.
krypted October 10th, 2015