Automating Locations with networksetup

The new location options in networksetup are pretty interesting and while I’ve mentioned them in writings in the past I thought I would explore scripting against them, as they do reflect an interesting new challenge, mostly if you’re looking to script against non-booted volumes. To script against a booted volume is fairly straight forward. You have the -listlocations, -getcurrentlocation, -createlocation, -deletelocation and -switchlocation options which lists all locations, lists the current location, creates a location, deletes a location and potentially switches a location. To get started, first look at what locations your system has:
networksetup -listlocations
If you are on a freshly installed system you should see Automatic as your only location. Therefore, that should be the output of the next option. But just to make sure, now use the -getcurrentlocation option to show your current location:
networksetup -getcurrentlocation
When you’re scripting the creation of locations you will use the -createlocation option. This option will allow you to create a new location without any network services created for that location. Let’s create an empty location called Work
networksetup -createlocation Work
This will create an entry in the /Library/Preferences/SystemConfiguration/preferences.plist. Each of these entries is marked with a unique identifier. That unique identifier is then referenced as a Set within the preferences.plist and as you create network services they are in turn referenced by a unique identifier within the set. While we’re creating locations we can go ahead and create one with the default set of network services (1 of each physical adapter). To do so, use the -createlocation option again, but this time follow it with a populate verb. We’ll use this location to setup a location for home.
networksetup -createlocation Homeq populate
Oops, did we misspell Home as Homeq, we should probably delete that and create the one we actually meant to create. To do so use the -deletelocation option and then add the Home location again:
networksetup -deletelocation Homeq
The -deletelocation option will amusingly output the string found it!
networksetup -createlocation Home populate
Next, in order to configure the various network services within each location you will need to switch to that location. Here, we will switch the active location using the -switchlocation option:
networksetup -switchlocation Work
With the appropriate location selected, use the -createnetworkservice, -removenetworkservice and -ordernetworkservices options to more granularly configure your locations, as I previously covered.

php from the Command Line

Using php at the command line isn’t an exact science in regard to which scripts that run in a web page will function from the shell. However, if you are automating many tasks, such as how you would go about with a shell script, then php is a nice alternative to other languages. To get started, let’s look at the version of php that we’re running. A quick way to test this is type the following from the command line.
php -v
This should result in something like the following message, which includes the version of PHP you are running and the current date:
PHP 5.3.0 (cli) (built: Jul 19 2009 00:34:29) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies
In its most basic form, the CLI interface can be used just like any PHP script. Create a sample script similar to the following, which we will save as test.php:
<?php print “This is a test.”; ?>
Next we will make this script executable by using the chmod command:
chmod +x test.php
You can execute this script by entering the following command at a shell prompt provided that you have executable permissions to the script:
php test.php
You can avoid calling the php command first on UNIX-based systems by placing a reference to the PHP program right at the start of the script. This tells the shell which program should be used to execute the script. Here’s an example:
#!/usr/local/bin/php <?php print “Hello World!”; ?>

Adding Color to & Customizing the Shell Prompt

As promised in the article on colorizing the terminal, let’s look at how to customize your bash prompt.  First note that text as well as the following can be used in your string.
  • a – ASCII bell
  • d – date
  • e – ASCII escape
  • h – LocalHostName
  • H – HostName
  • j – number of jobs managed by shell
  • l – basename of terminal device name
  • n – insert a newline
  • r – insert a carriage return
  • @ – time in 12-hour HH:MM format
  • A – time in 24-hour HH:MM format
  • t – time in 12-hour HH:MM:SS format
  • T – time in 24-hour HH:MM:SS format
  • u – current user
  • v – include bash version
  • V – include bash version & patch level
  • w – working directory, w/ $HOME
  • W – basename of working directory, w/ $HOME
  • ! –  history number of command
  • # – command number
  • $ – # if the UID is 0 or a $
  • \ –  backslash
  • [ – start sequences of non-printing characters
  • ] – used to end sequences of non-printing characters
Using the above then, you would indicate the prompt in the .bash_profile and add a new line that starts with PS1 along with the codes you’d like to use in quotes. For example, to show the path followed by a colon (:) and then the LocalHostName you could use the following:
PS1=”h : u $ “
Or to add the time in the beginning of the line:
PS1=”T : h : u $ “
To insert some text, simply place characters inside the quotes. Let’s replace the $ with the word Prompt:
PS1=”T : h : u Prompt “
Now that we’ve done a little customization let’s look at adding some color. Before doing so, consider what color and the codes that can be used per color:
  • Black – 0;30
  • Blue – 0;34
  • Light Green – 1;32
  • Green – 0;32
  • Light Cyan – 1;36
  • Cyan – 0;36
  • Light Red – 1;31
  • Red – 0;31
  • Light Purple – 1;35
  • Purple – 0;35
  • Light Brown – 1;33
  • Brown – 0;33
  • Light Blue – 1;34
Once you pick a color then let’s look at adding a little Cyan to your prompt:
export PS1=”e[0;36m[u@h w $”
export PS1=”e[0;36m ] u@h w $”
Finally, you can add multiple colors, making your prompt a little clown-like. But I am not sure that I’d recommend that (seems a little distracting). One thing I do sometimes is to set the command that I’m typing to a different color.  For example, to set it to green if that’s what you’re coming back in from
export PS1=”e[0;36m ] u@h w $ e[0;32m ]”
So customize away and enjoy!

10 Quick SysAdmin Time Savers

I’m not gonna’ lie to you, I’m a pretty lazy admin. As such, I look for ways to reduce the amount of typing I have to do routinely. And ways to not make mistakes that I made when I was young and needed the rupies. The more time I spend at the command line, the more I use these, so here goes (hope they help you in some way shape or form):
  1. Make your own bin and put stuff you use often in there.  You can use any folder you like and just include it in the export PATH=$PATH line by throwing a : at the end and typing that path.
  2. A great example of this is stroke, the port scanning tool from Network  I know, I know – there are way better port scanners out there, such as nmap.  Scoff at me if you will (especially if you’re Fyodor) – but it’s just friggin’ easy to use and for generic troubleshooting it gets the job done without much fanfare…  So I copy the stroke command out of the Network bundle into my own bin and from there I can summon it with ease.
  3. Add the bin for other common tools to your PATH.  For example, the ec2 tools, if you’ve been following along with that series of articles.
  4. Don’t rm, mv.  So it’s more typing…  But not so much if you build a shell script to do it.  There’s a great example of that in the Shell Scripting Recipes book by Chris F.A. Johnson from Apress.  Over time, pulling something out of the trash rather than having to go and find something from outside of your machine because you accidentally deleted it will save you time.
  5. Provided your machine is secure, use preshared keys with servers you log into routinely.
  6. Automate everything you can – launchd is your friend.  Automation isn’t just for deployment folks.  You automate your backups, your log rotations and other tasks, so why not automate as much as possible.
  7. But don’t overautomate.  If it takes you longer than it will save over the lifecycle of a script, why bother.  Also, automating items that are moving targets (eg – log review for 3rd party software that gets a lot of updates) can be questionable.
  8. Clone before you update, or update into a lab environment and then push to production.  It doesn’t happen a lot but some vendors will release buggy patches.  Rather than get spun into a scenario where you’re chasing down issues, just do testing due diligence in a lab and/or clone machines before you roll updates into a production environment.
  9. Don’t reinvent the wheel.  Sure, you might like to compile your own software, but if you don’t need the options in the latest .01 release and it’s part of MacPorts then maybe it would be quicker to install from there.  Maybe not…  If you do like to compile stuff yourself, maybe post to MacPorts (after all, what goes around comes around).  On the deployment side, why build your own packages even though a piece of software is distributed as a package…  Ask yourself if you really think you can do a better job than the vendor does, while knowing that occasionally (regrettably) you’ll say yes.
  10. And of course, use the latest and greatest terminal features, such as tabbed terminal windows.
I’m sure others out there will have their own lists, but these are the big ones that pop up in my mind…

Mac OS X: Require Password at Single User Mode

By default, Mac OS X will simply give you a shell when you perform a Single User Mode startup.  However, you can force OS X to ask for a password in order to gain shell access.  To do so, vi the /etc/ttys and change secure to insecure.  Once you have done so, create a password in /etc/master.passwd for root.