When I was speaking at MacADUK, I asked Tom Bridge about starting a podcast. He’s got a great voice, and I thought he’d be a great co-host. Before we were able to get to that when we got home, Adam Codega, independently of the conversation I’d had with Tom, dropped a note on Twitter to see who else might be interested in doing a Podcast. A few people responded that they’d be interested in also jumping in on a new Podcast. Over the next few weeks, decisions were made that the podcast would be hosted as a part of MacAdmins.org, the format, the hosting location, and lots of other really cool stuff. And some of us got together and recorded the first episode. And then, last night, we recorded the second episode just in time to get that into editorial before Episode 1 is released.
And soooooo, episode 1 is out! It includes Tom Bridge, Emil Kausalik, Adam Codega, and myself. We also have an interview with some of the organizers from the Penn State Mac Admins conference, which I wasn’t able to sit in on, but find just fantastic. And Tom did some of the editing. Aaron Lippincott (@dials-Mavis) did a lot of work on the mastering and deserves lots of credit there (he made everyone sound way betterer). And John Kitzmiller did a lot of work on the domain and website and DNS type of stuff, as well as helping with hosting of the podcast assets as well. And Adam’s done a lot of work on the back end linking things together, so a great team effort.
The next episode also features Pepijn Bruienne and Marcus Ransom (who I lovingly decided we should call the He-Man of the Mac Universe) and covers the latest iOS 9.3 release, as well as some information about the Classroom app. So stay tuned for that, but click below to give the episode a listen, or find on iTunes once it appears (and I’ll post a link to that once we can).
Overall, I’m really stoked to get this thing going, and that the group has built a great system for future episodes, that should be sustainable for many, many episodes. I’m also really stoked to be able to get to work with this specific group – I’m a big fan of everyone, and I look forward to many episodes to come! So follow on Twitter at @MacAdmPodcast
and feel free to let us know if you’ve done something awesome and we should mention it or interview you!
krypted March 28th, 2016
Posted In: iPhone, Mac OS X, Mac OS X Server, Mac Security, Mass Deployment, Network Infrastructure, personal
@macadmpodcast, Apple, Apple Devices, ios, iPhone, MacAdmins, podcast
Who still says “like a boss?” I guess I did. Get over it. But don’t get over spam. Especially annoying are the ones we know we accidentally signed up for. Because it’s our own darn fault. But luckily, there’s a lot more tools for dealing with bulk mail (solicited or unsolicited) these days. Most modern email clients have the ability to deal with spam. Exchange/Office 365 has clutter and junk. You can build rules on sites. You can use spam assassin on your servers. But, there’s also a nice little app called unroll.me. Once you sign up you’ll have 3 ways of dealing with each message: request removal from a list, mark as rolled up into a single daily digest, or mark as good email.
Download it here.
The app works a lot like something like Tinder. You swipe right to like something, left to not like something. Facebook should implement this into your timeline!
If you decide to mark emails as digests, you’ll get an email once a day that looks like this:
This works great for organizations that actually properly remove you from lists (which is surprisingly most). Using this swiping type of workflow, you can knock through 100 or more emails in 10-15 minutes. For organizations that don’t respect unfollow or stop sending me your crap emails, there’s also always just marking them as spam. The only problem with this is that you likely have a phone, a computer, a home computer, and maybe a tablet. No one wants to mark the same email as spam four times and then potentially have emails disappearing and not being able to figure out which computer they were marked as junk on.
There are lots and lots of options for this type of thing. But given the ease of use an quick evisceration I can do on my mailbox, I rather like unfollow.me. Give it a shot. You might hate it. I don’t.
krypted December 3rd, 2015
Posted In: Apps, cloud, Network Infrastructure
ios, iphone app, mass unenroll, remove spam, spam, unenroll
There’s a quick and easy IT Business Edge slideshow at http://www.itbusinessedge.com/slideshows/the-5-mobile-apps-you-really-need-for-smb-success.html
that I helped with about 5 Mobile Apps You Really Need for SMB Success.
Hope you enjoy!
krypted August 10th, 2015
Posted In: Bushel, iPhone, Mac OS X, Mac OS X Server, Mac Security, Mass Deployment, Network Infrastructure
apps, Connect, edit documents, ios, Servers
Mac admins spend a lot of time building images. In System Image Utility this can mean baking an image that just looks for a path of a NetRestore source and restores an operating system. Constantly making these is a pretty duplicative task. The goal of this article is to take a generic NetRestore NetBoot image and augment it in such a way that you don’t need to create new NetBoot images unless there’s a new build train. Instead, all you need to do is edit a file that changes the path (uri) of your image so that it can be restored. Using this, you can just stop the NetInstall service in OS X Server, edit a file, start the service back up and boot clients into the NetBoot environment.
When you make a NetBoot Set, you’ll select a source. This can be a local volume or a network volume. Once your NetBoot nbi is created, you’ll see a NetInstall.dmg. If you open that dmg, you’ll see a directory called Packages. If you open that, you’ll see an InstallPreferences.plist.
Let’s cat that real quick:
The output would be as follows:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
Here, let’s look at a few specific keys that we can edit:
- descriptionKey: A simple, human readable description of the image that will be installed
- sourceKey: The URI to the image that asr will connect to in order to install the image
sourcePath: This is the path to the dmg file within the nbi. This is usually best left untouched unless you’ve switched something around within the nbi (which I’ve only seen done a couple of times).
- restoreSourcesBrowseMulticast: Set to true to allow for multicast imaging. Obviously, DeployStudio or asr would be used to make this work and you’d need to provide a multicast address.
- installRecoveryPartition: Set this to false if you don’t want to install a recovery partition. You probably should be creating one.
- restoreSourcesAllowManual: Allows for manual entry of an image source.
- restoreSourcesBrowseOthers: Allows for browsing over Bonjour for an image source.
- restoreSourcesArray: Not present if you chose a local path.
You can also edit the NBImageInfo.plist file to set some of the other items you might otherwise edit in System Image Utility. Here, you’ll need to covert the plist to xml to edit it:
plutil -convert xml1 /Volumes/NetBootSP/NetInstall\ OS\ X\ Yosemite.nbi/NBImageInfo.plist
In here, you’ll see a plist similar to the following:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
The important keys to look at here are:
- SupportsDiskless: Switch this on and off if you want NetBoot to run for diskless systems (e.g. if you’re a 3 letter government agency).
- Index: Typically use unique index IDs.
- IsDefault: Makes that image the default image.
- RootPath: The path to that NetInstall.dmg file from earlier.
- ImageType: netrestore versus netinstall.
- DisabledSystemIdentifiers: Disables certain models of Macs, which you’d edit by adding and removing items from that array.
So you can edit these files, and once you do so, you won’t need to be baking NetBoot sets all the time. Just when there’s a new build train of OS X and you can’t boot those new machines to NetBoot.
krypted July 9th, 2015
Posted In: Mac OS X, Mac OS X Server, Mass Deployment, Network Infrastructure
descriptionkey, installrecoverypartition, NetBoot, NetInstall, netinstall.dmg, NetRestore, restorelist, restoresourcesarray, sourcekey
sFlow is an industry standard that allows network equipment with the appropriate agents to send data to sFlow collectors, which then analyze network traffic. You can install sFlow on routers, switches, and even put agents on servers to monitor traffic. Brocade (along with most other switch manufacturers) supports sFlow.
Before you do anything log into the switch and check the current flow configuration:
To configure, log into the switch and use the the int command to access an interface. From within the interface, use the following command:
Then exit the interface using the very difficult to remember exit command:
Repeat the enablement of forwarding for any other necessary interfaces. Next, we’ll configure a few globals that would be true across all interfaces. The first is the destination address, done using the destination verb followed by the IP and then the port (I’m using the default 6343 port for sFlow):
sflow destination 192.168.210.87 6343
Set the sample
sflow sample 512
Set the polling interval:
sflow polling-interval 30
Finally, enable sFlow:
krypted January 2nd, 2015
Posted In: Mac OS X, Mac OS X Server, Mac Security, Network Infrastructure, Xsan
brocade, destination, enable, network flows, port, san, sflow, switching, UDP, Xsan
The other day, my daughter said “it’s opposite day” when it was time to do a little homework, trying to get out of it! Which reminded me of a funny little command line tool called rev. Rev reads a file and reverses all the lines. So let’s touch a file called rev ~/Desktop/revtest and then populate it with the following lines:
Now run rev followed by the file name:
Now cat it:
Now rev it again:
You go go forward and back at will for fun, much more fun than homework… Enjoy!
krypted December 12th, 2014
Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment, Network Infrastructure, Programming, Ubuntu, Unix
bsd, code, homework, MAC, opposite day, os x, rev, reverse file lines
OS X has a command called rvictl, which can be used to proxy network communications from iOS devices through a computer over what’s known as a Remote Virtual Interface, or RVI. To setup an rvi, you’ll need the udid of a device and the device will need to be plugged into a Mac and have the device paired to the Mac. This may seem like a lot but if you’ve followed along with a couple of the other articles I’ve done recently this should be pretty simple. First we’ll pair:
Then tap Trust on the device itself. Then we’ll grab that udid with idevice_id:
Next, we’ll setup a rvi with rvictl and the -s option (here I’m just going to grab the udid since I only have one device plugged into my computer):
rvictl -s `idevice_id -l`
Then we can list the connections using rvictl with the -l option:
Next, we’ll run a tcpdump using this newly constructed rvi0:
tcpdump -n -i rvi0
Next, we’ll get a lot of logs. Let’s fire up the Nike FuelBand app and refresh our status. Watching the resultant traffic, we’ll see a line like this:
22:42:29.485691 IP 192.168.0.12.57850 > 22.214.171.124.443: Flags [S], seq 3936380112, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 706439445 ecr 0,sackOK,eol], length 0
There’s an IP in there, 126.96.36.199. We can look this up and see that the servers are sitting on Amazon Web Services and verify it’s Nike. Watching the traffic with tcpdump we can then obtain GET, POST and other information sent and received. Using wireshark we could get even more detailed data.
Overall though, this article is meant to focus on the iOS side of this and not on debugging and refining the approach to using tcpdump/wireshark. rvictl is a great tool in the iOS development cycle and for security researchers that are looking into how many of the apps on iOS devices exchange data. Enjoy.
krypted November 19th, 2014
Posted In: iPhone, Mac Security, Network Infrastructure
Apple security, get, ios, iPad, iPhone, MAC, POST, rvictl, tcpdump, view network traffic
Xcode and other tools can be used to view logs on iOS devices. One of those other tools is libimobiledevice
. I usually install libimobiledevice using homebrew, as there are a few dependencies that can be a little annoying. To install homebrew if you haven’t already, run the following command:
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
Once run, follow the prompts to complete the installation. Once homebrew is installed, run the following brew command to download the required components and then libimobiledevice:
brew install -v --devel --fresh automake autoconf libtool wget libimobiledevice
Then run ideviceinstaller:
brew install -v --HEAD --fresh --build-from-source ideviceinstaller
Once these are installed, you can plug in a paired device, unlock it and use the following command to view the logs on the screen:
This is akin to running a tail against the device. Again, the device must be paired. You can use the command line (e.g. if you’re running this on Linux) to view the logs, but if you’re not paired you’ll need to use idevicepair to pair your device, followed by the pair verb (which is very different from the pear verb):
You can also unpair using the unpair verb:
When pairing and unpairing, you should see the appropriate entries in /var/db/lockdown. The final option I’m going to cover in this article is the date (very useful when scripting unit tests using this suite. To obtain this, use the idevicedate command, no operators or verbs required:
krypted November 14th, 2014
Posted In: iPhone, Mac OS X, Mac OS X Server, MobileMe, Network Infrastructure
/var/db/lockdown, homebrew, idevicedate, idevicepair, idevicesyslog, install, unpair, view iOS logs, view iPad logs
« Previous Page
The Directory Utility application has moved to /System/Library/CoreServices/Applications. Once open, you can use it to bind to directory services, change search policies and even dink around with NIS if you still rock the flannel with your ripped up jeans. But, the thing that I tend to do in Directory Utility the most is look at user and group attributes. To do so, open Directory Utility and click on the Directory Editor tab. In the bar directly below, you’ll see Viewing and In Node. The Viewing option is what type of object you’re going to look at. The In Node option shows the directory domain you’re viewing. Below, we show the local users in /Local/Default.
Click on a user and you will see all of the attributes that exist for that user. Not all users are created equal when it comes to attributes, so if you’re looking for a specific attribute then you can go through different users to see what they have.
Change the In Node option to /LDAPV3/127.0.0.1 (or the name of your directory service such as your Active Directory) to see all the attributes available there. You can then note the names and use them in scripts, etc.
You can also access this information via dscl, but I’ve covered that enough times in the past to be bored with myself for even making the reference. Enjoy.
krypted November 6th, 2014
Posted In: Mac OS X, Mac OS X Server, Mac Security, Network Infrastructure
Apple, Directory Utility, LDAP, Mac OS X, OpenLDAP
— Next Page »