While discussing various issues with a colleague, he mentioned that he was seeing the root account enabled on several machines where it should not have been. In general, the root account on macOS is not needed for system administration and should be disabled so he asked if there was a way to use the dsenableroot command to disable the root account without also needing to provide a password.
Unfortunately, disabling the root account by using the dsenableroot -d command does require providing a password as part of the command.
However, it is possible to disable logins to the root account without using the dsenableroot -d command. For more details, see below the jump.
I had one of my customers report a problem today after applying software updates to his Mac. His Mac had been able to automount certain network shares via NFS before the updates, but was unable to access those shares following the updates.
I connected remotely to the Mac and verified that I was unable to manually mount the NFS mounts.
When I tried to run the showmount command to get a list of the available NFS mounts on the server, I also received a timeout message:
I was about to send this on to the team that handled our NFS shares, when I remembered I hadn’t verified that I could access the server. Sure enough, I couldn’t:
I could ping Yahoo however, so I could contact the internet.
So I couldn’t access an internal network resource, but I could access the internet. What made this puzzling was that I was connecting remotely to the Mac via the IP address associated with this person’s Ethernet address. This IP address should not have had issues accessing internal network resources. What had happened? For more, see below the jump.
While working on some documentation, I noticed a behavioral change in macOS Sierra’s sudo tool that was different from how sudo behaves on OS X El Capitan.
if you run sudo in one Terminal session and authenticate with your password, then open another Terminal session and run sudo, you won’t be prompted for your password in either Terminal session until the normal sudo authentication timeout. To see what this behavior looks like, please see the video below:
If you run sudo in one Terminal session and authenticate with your password, then open another Terminal session and run sudo, you’ll get asked for your password in the second Terminal session too. Meanwhile, in the first Terminal session, you won’t get prompted again until the normal sudo authentication timeout. To see what this behavior looks like, please see the video below:
The difference is that Apple has compiled sudo on Sierra to include the tty_tickets option, which ensures that users need to authenticate on a per-Terminal session basis.
This option had not been included in sudo on OS X El Capitan and earlier, which had been viewed as a privilege escalation vulnerability.
If you want sudo to return to using the pre-Sierra behavior on macOS Sierra, edit /etc/sudoers to add the following option:
While working with different versions of Mac OS X and macOS, it’s often been useful to me to be able to export the contents of a particular command line utility’s Unix man page to a plain text file. Man pages are the built-in documentation method available in Unix-based systems, so Apple documents how to use the various command line tools used by the operating system using this documentation method.
Exporting to a plain text file allows me to compare macOS Sierra’s man page for a particular command line utilty to a exported copy of the same utility’s man page from OS X El Capitan and see where changes to the man page have been made. This comparison is made by using diff, or other file comparison tools like Kaleidoscope, which helps me quickly spot where Apple has made changes to their documentation.
To export man pages to a plain text file, I use the col command line utility to read the contents of the man page in using stdin, then export out to a plain text file using stdout As an example, here’s how to use col to export the diskutil man page to a new plain text file named diskutil.txt:
man diskutil | col -bx > /path/to/diskutil.txt
In this case, col‘s -b and -x functions are used to make sure that the formatting for the diskutil man page remains intact when exported to the plain text file.
In some environments, it may be desirable to give users admin rights while restricting those users from being able to run commands with root privileges while using the command line.
A way to achieve this “admin user in the GUI, standard user on the command line” method is to edit the /etc/sudoers file. This is the configuration file referenced by the sudo command line tool, which allows a user with the correct sudo rights to execute a command with root privileges, or using another user account’s privileges.
By default, all user accounts with admin rights on both OS X and macOS have full rights to use the sudo tool. By removing those accounts’ rights for sudo from the /etc/sudoers file, user accounts with admin rights will not be able to run commands with root privileges using the sudo tool. For more details, see below the jump.
One of the challenges Casper admins can run into is performance tuning, which can require going into parts of the JSS that you normally go into only when JAMF Support asks you to do so. To help with this process, there are formulas which you can use to calculate if your JSS’s Tomcat and MySQL services are configured for best performance.
Before proceeding further, I want to emphasize that a) check with JAMF Support first and b) you should always, always, always make backups of your JSS before changing settings. I assume no responsibility and bear no culpability if your JSS breaks as a result of anything you implement as a result of reading this post. I am also not responsible for incorrect math, ruining anyone’s weekend, or that long talk you now need to have with your boss about why your JSS is now broken.
One other thing to be aware of is that I’m going to be focusing on Linux and Windows in this post since those are the platforms that I’m most familiar with for hosting a Casper 9 JSS.
For more details, see below the jump:
In the wake of the release of Casper 9.8, where the Casper agent’s jamf and jamfAgent binaries have made their planned move from /usr/sbin to /usr/local/jamf/bin, a number of Casper-using folks who were used to running commands that referenced the jamf and jamfAgent binaries from Apple Remote Desktop (ARD) or other tools began to see errors that indicated that the jamf and jamfAgent binaries could not be found.
Conversely, opening a Terminal session and running the exact same command works fine.
Why are different tools acting differently? The root cause is that they each have different PATH environmental variables, usually referred to as $PATH. For more details, see below the jump.