Before IRC, AOL Instant Messenger and Apple’s Messages, there was talk. talk is a Unix text chat program, allowing messaging between users of Unix-based systems. While it’s been largely superseded by other chat applications, it’s still included with OS X Mavericks as the ntalk service.
Setting up a talk server on OS X
To start the talk server on OS X, run the following command to start the ntalk service:
sudo launchctl load -w /System/Library/LaunchDaemons/ntalk.plist
To stop a running talk server, run the following command to stop the ntalk service:
sudo launchctl unload -w /System/Library/LaunchDaemons/ntalk.plist
It’s pretty straightforward to use talk. To talk to another user logged in on the same host, use this command:
To talk to a user on another host, use this command:
Once communication is established, the two parties may type simultaneously, with their output appearing in separate windows. One thing to know is that output is reflected live to both sides; every character typed (typos and all) will be visible.
Reprint screen – Typing control-L will cause the screen to be reprinted.
Clear screen – Typing control-D will clear both parts of your screen to be cleared, while the control-D character will be sent to the remote side (and just displayed by this talk client).
Exit current talk session – To exit, type control-C.
For more information on talk, please see the man page:
As part of a project to assess the deployment options for National Instruments’ LabVIEW 2013 Pro, I was asked to see if I could deploy it through Casper’s Self Service. After some work, I was able to repackage the installer in a way that deploys smoothly. In the process, I saw a number of ways that this particular installer went against The Commandments of Packaging. See below the jump for details.
One of my users ran into an issue recently when launching Microsoft Lync. When the Lync application logged into the Lync server, a Microsoft Lync wants to use OC_KeyContainer_username@company.com. Please enter the keychain password prompt appeared.
The curious thing was that the keychain prompt would not accept the user’s current login password. When I checked, the user’s login keychain was unlocked and using the current password, so it didn’t appear to be caused by the login keychain password issues that I normally deal with.
After some research, I was able to find the answer and get this issue fixed. See below the jump for the details.
Upgrading a FileVault 2 encrypted Mac to 10.9 – Differences between CreateOSXInstallPkg and Apple’s Mavericks installation methods
I was recently wrong on the internet again, but as always making a mistake gave me a chance to learn from it. What I learned was the method Mac admins choose to use upgrading their Macs to Mavericks may have behavior that apply specifically to FileVault 2-encrypted Macs. See below the jump for details.
As part of a domain migration project, I was recently tasked with figuring out a way to handle migrating the Macs from one AD domain to another. I had the following requirements:
- Unbind the Mac from the old AD domain
- Bind the Mac to the new AD domain
- Migrate the user’s data from the old AD domain to the new AD domain
Preferably, it would be a procedure that anybody could use. That way, anyone on the team could be perform the migration process regardless of their personal skill level with Macs.
I had a pre-existing interactive script that I could modify and use to fulfill requirement 3, but I needed a way to fulfill requirements 1 and 2.
With some help from DeployStudio, I was able to develop an unbind / rebind procedure that fulfilled requirements 1 and 2. It also gave me the following features:
- Anyone on our helpdesk team could do it, regardless of familiarity with Macs or Active Directory.
- Potential for human error was minimized
- Reboots (generally a good idea when making directory service changes) were a built-in part of the migration process.
For details, see below the jump.
A while ago, I needed to script a method for binding Macs running 10.6.x and later to our Linux-based OpenLDAP server. Recently, we needed to move our OpenLDAP domain to a different OpenLDAP domain as part of a larger directory service migration project. A small part of that project was moving the LDAP-bound Macs to the new LDAP domain, preferably with as little disruption as possible.
One enormous advantage I had with this LDAP move was the following:
All UIDs, GIDs, usernames, passwords and group names were going to be identical between the two LDAP domains.
As a consequence, I would not need to do any permissions changes, rebuild accounts, make sure people got new passwords or a host of other things normally associated with a directory service change. My task was essentially to tell the Macs “Stop talking to the OpenLDAP service at that address, start talking to this other OpenLDAP service at this address”
As part of the project, I also wanted to accommodate two separate Active Directory domains differently. I wasn’t binding to AD as part of this process, but if a particular Mac was bound to Domain A, I wanted to unbind. If a Mac was bound to Domain B, I didn’t want to unbind but I did want the new LDAP server to be the primary authentication source.
Using my previous OpenLDAP binding script as a starting point, I was able to build a script to handle moving our Macs without downtime or account changes. See below the jump for details.