This week’s Techno Bits has juicy tidbits from the Infocom Era, as well as the aftereffects of security failures, a sysadmin gift guide, and some thoughts on repairability.
I have a complicated relationship with the winter months, due to seasonal affectation, but one thing I love is giving gifts. I’ve set up Sysadmin Secret Santa to help bring some fun to the Sysadmin community this time of year.
This week’s Techno Bits is up! Talking about Command Prompt Marks in El Capitan, MAS Failures, and General Security. Sign up today!
When Rich Trouton recently blogged about automating the setup of Server.app, we talked a bit about how it might apply to Munki in a Box. The idea of having a version that you could run entirely without having to have pre-loaded Server.app was attractive, as it would save steps.
On the heels of the work earlier this week with getting webappctl tamed for use at the command line, I had all the pieces necessary to complete the project, just a week after commissioning.
To use this script to its fullest, you need a copy of the AppStore Installer Package for Server.app (here’s how to grab it), as well as a good hostname to use for your server. That means the hostname needs to be ready in your DNS for the script to work. I suppose I could write a check for that, and will for beta 2.
But for now, 1.5.0 beta 1.
My appearance on Command Control Power from last week is now live! Come listen to an hour about Mac Consulting!
Apple’s Server.app offering has a strong command line interface that is usually tied to the serveradmin command verb. This is great when you want to start or stop the web service, as well as view all of the Apache settings:
sudo serveradmin start web sudo serveradmin stop web sudo serveradmin settings web
But the thing I really, really wanted to do with serveradmin was turn on the PHP Web Application, because Munkireport-PHP relies on it being running, and if serveradmin can’t engage the PHP application engine, I was going to be unable to control it programmatically, or view its status with a check.
I submitted a bug to Apple that it wasn’t available as part of serveradmin, and I fully expected it to be closed with “functions as intended.”
And it was!
But there was a pleasant note at the bottom below:
You can enable/disable PHP from the command line, just not with serveradmin. The supported way is:
sudo webappctl [start|stop] com.apple.webapp.php
This, of course, got me reading the (ample) manage for webappctl.
webappctl recognizes the start or stop argument to activate or de-activate the webapp specified by webapp-name. If the webapp-name is specified as "-", the start/stop/status action applies to all webapps represented with a plist present in /etc/apache2/webapps/. In the case of a restart "-" action, the set of running webapps are stopped, then started. (In the case of a restart for a specific webapp, the webapp will be stopped, then started, even if it was not running before.) If the status argument is specified, a list of enabled webapps is displayed. The tree[s] argument displays the hierarchy of webapps declared by the requiredWebApps property. The optional vhost-name argument specifies the name of the virtual host though which the webapp is to be proxied. If omitted the default wild-card virtual host is used.
This means that you can easily start or stop the PHP and Python web applications programmatically with the following commands:
sudo webappctl start com.apple.webapp.php sudo webappctl stop com.apple.webapp.php sudo webappctl start com.apple.webapp.wsgi sudo webappctl stop com.apple.webapp.wsgi
As well as get their status from the command line:
vm1011:apache2 ladmin$ sudo webappctl status - web:webAppState:_array_index:0:virtualHostName = "-" web:webAppState:_array_index:0:vhid = "-" web:webAppState:_array_index:0:state = "RUNNING" web:webAppState:_array_index:0:webAppName = "com.apple.webapp.php" web:webAppState:_array_index:1:virtualHostName = "" web:webAppState:_array_index:1:vhid = "127.0.0.1:34543_" web:webAppState:_array_index:1:state = "RUNNING" web:webAppState:_array_index:1:webAppName = "com.apple.webapp.wsgi" web:webAppState:_array_index:2:virtualHostName = "" web:webAppState:_array_index:2:vhid = "127.0.0.1:34580_" web:webAppState:_array_index:2:state = "RUNNING" web:webAppState:_array_index:2:webAppName = "com.apple.webapp.wsgi" OR vm1011:apache2 ladmin$ sudo webappctl status - web:webAppState:_array_index:0:virtualHostName = "-" web:webAppState:_array_index:0:vhid = "-" web:webAppState:_array_index:0:state = "RUNNING" web:webAppState:_array_index:0:webAppName = "com.apple.webapp.php"
This opens the door further for a version of Munki in a Box that could configure Server.app if it isn’t already, including the activation of the web service and the PHP web application service. This is good news.
A presentation from the MacTech Conference, 2015, in Los Angeles, CA.
One of the projects I’ve been working on for the last year is Munki in a Box, designed to take your bare Mac server to being a fully-implemented and ready-to-roll Munki server with automatic management through AutoPkg and AutoPkgr, GUI configuration through MunkiAdmin, as well as an inventory control scheme using Munkireport-PHP.
You can read up on the project at Github, and I’ll be updating this blog going forward with more details.
Version 1.4.0 is the current release, and it contains everything you need to get up off the ground.
Version 1.5.0 is in development, and will handle configuration of your OS X Server immediately after download of the Server.app binary, all from the command line.
My presentation from the Penn State Mac Admins Conference, 2015.
You can download a PDF copy if you like.