Archive
Automating Oracle Java 8 JDK updates
To go along with a previous post about automating Oracle Java 8 updates, I’ve now posted a script to download and install the latest Java 8 Java Development Kit (JDK) from Oracle. Oracle has been releasing two separate versions of Java 8 simultaneously, so this script is designed to allow the user to set which version they want to install: the CPU release or the PSU release.
The difference between CPU and PSU releases is as follows:
- Critical Patch Update (CPU): contains both fixes to security vulnerabilities and critical bug fixes.
- Patch Set Update (PSU): contains all the fixes in the corresponding CPU, plus additional fixes to non-critical problems.
For more details on the differences between CPU and PSU updates, please see the link below:
http://www.oracle.com/technetwork/java/javase/cpu-psu-explained-2331472.html
For more information, see below the jump.
MacAdmin 101: The root user account
An issue that can pop up for new Mac admins is whether or not to enable the root account on the Macs in your environment. By default, the root account on OS X and macOS is a disabled account with the following settings:
Display name: System Administrator
Account name: root
UID: 0
Home directory: /var/root
User shell: /bin/sh
The root account is the superuser for a Unix-style operating system like OS X and macOS and Unix is designed to let the root account have total access to everything. When asking what root can do on a system, it may be better to ask what root cannot do because that list is very, very short. Because the root account has enormous power on a Unix system, you may believe that enabling the root account and using it for your system administration tasks is a no-brainer.
In fact, the opposite is the case: It’s better to leave the root account disabled and not use it for system administration.
Why should you avoid logging into the root account and running tasks from there?
- Mistakes happen – When logged in as the root account, you have total access to the system and anything you run while logged in as root will just happen. That also means you can do a lot of damage if you make a mistake.
- Malware and software bugs – Being logged in as the root account means that all the applications you’re using are running with the root account’s privileges. That means every vulnerability and bug in those applications can potentially cause havoc on your system because anything that’s executing an undesired behavior or exploiting a vulnerability in a particular application is doing so using the root account’s rights to go anywhere and do anything on your system.
- Auditing: If multiple people are logging into the root account and using it for system administration, that means that the account in question isn’t necessarily tied to a single person and actions taken while logged into the root account aren’t necessarily logged. That makes it harder to figure out after the fact who did what if there’s a problem.
- It’s not necessary: The sudo command line tool is available and installed by default on both OS X and macOS. sudo is a Unix program which allows a user with the correct sudo rights to execute a command using the security privileges of another user account, with the root account’s security privileges being used by default.
Using sudo is safer than using the root account for the following reasons:
- Nobody needs to know the root account’s password – sudo prompts for the current user’s password and will check to see if the user which is trying to use sudo has the necessary rights for sudo to run the requested commands with root privileges.
- The granting of root privileges is temporary – By default, sudo will time out after fifteen minutes and will require re-authentication before running commands again.
- Only those commands run via sudo are using root privileges – Only the commands run using sudo will be run with root privileges. Meanwhile, commands run without sudo are being run without root privileges, which reduces the potential for damage from making a mistake.
- sudo use is logged – When a command is executed using sudo, the command and the account which used sudo to run it are logged. Likewise, unsuccessful attempts to run commands with sudo are also logged. This provides an easy way to look up which commands were run and who ran them.
For more information on using sudo, see below the jump.
Session videos now available from X World Conference 2016
The good folks behind X World have now posted the session videos from X World 2016. All are accessible from the X World 2016 YouTube playlist page, which is available via the link below:
https://www.youtube.com/playlist?list=PLUzsToqd-eE8-yMclT6qzh2lUP-XI0uvD
As all the session videos have been posted to YouTube, I’ve linked my OS X Security: Defense in Depth session here:
The Documentation – Why All The Cool Kids Are Doing It session is linked here:
MacAdmin 101: Building a recovery partition installer package using Create Recovery Partition Installer.app
As part of the process of deploying Macs in my shop, it is occasionally necessary to image or re-image them with a disk image containing the latest version of OS X or macOS. To assist with making sure that the Mac’s recovery partition is correctly applied as part of the imaging process, an installer package which installs or repairs recovery partitions is installed as part of the imaging process.
When I need to create recovery partition installers, I use an application named Create Recovery Partition Installer.app to generate them. Create Recovery Partition Installer.app is an open-source tool written by Per Olofsson that lets you create an installer package that creates and updates recovery partitions on boot drives for both OS X and macOS.
For more details on how Create Recovery Partition Installer.app can be used to build recovery partition installers, please see below the jump.
MacAdmin 101: Building Mac disk images using AutoDMG
As part of the process of deploying Macs, it is occasionally necessary to image or re-image them with a disk image containing the latest version of OS X or macOS. When I need to create disk images for use in my shop, I use an application named AutoDMG to generate them. AutoDMG is an open-source tool written by Per Olofsson which enables the creation of never-booted OS X or macOS images for deployment.
Why is creating a never-booted disk image important? When you boot a Mac for the first time, the OS will create a number of system-specific settings, temporary files and other associated system-specific data. Because this data is specific to an individual Mac, it doesn’t always transfer well to other Macs and may cause some quirky issues. By creating a never-booted disk image, you avoid the issue entirely because those files aren’t created as part of the image building process and consequently do not get transferred to Macs which are set up using the disk image.
When building an image using AutoDMG, the best approach is to build an image containing just the operating system and available updates included in the image. While you can also choose to include other software installers in your image build process, a lot of software installers won’t apply correctly to the image because the affected installers use scripts and other functionality which do not run properly when run as part of AutoDMG’s image creation process.
Because of this behavior, I recommend planning to install software as a post-imaging task as opposed to including it in your AutoDMG-generated disk image. For those interested, additional information on this topic is available from the Getting Started section of the AutoDMG wiki.
For more details on how AutoDMG can be used to build images, please see below the jump.
Exporting Unix man pages to plain text files
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.
Editing /etc/sudoers to manage sudo rights for users and groups
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.
Slides from the Documentation session at X World 2016
For those who wanted a copy of my documentation talk at at X World 2016, here are links to the slides in PDF and Keynote format.
PDF – http://tinyurl.com/XWorld2016DocPDF
Keynote – http://tinyurl.com/XWorld2016DocKeynote
Running Apple’s System 1 on OS X El Capitan
As part of some research which I’m doing on Mac filesystems, I wanted to see if it was possible to get Apple’s System 1 running on OS X El Capitan. The reason that I am specifically interested in System 1 is that this OS used Apple’s shortest-lived filesystem: Macintosh File System.
After discussing the issue, my colleague @mikeymikey pointed me in the direction of using the Mini vMac emulator application to accomplish this. He also pointed me towards the correct places where I could download a System 1 disk image and the needed Mac ROM file.
With this information, I was able to get System 1 up and running inside of the Mini vMac emulator. For the details, see below the jump.
Creating a screen recording of a second display with Apple’s QuickTime Player
One of the features of Apple’s QuickTime is that it allows a video recording to be made of your screen. This allows whatever you’re doing on the screen to be captured in a video and played back later.
To use QuickTime Player on OS X El Capitan to make a screen recording, use the procedure described below:
1. Launch QuickTime Player
2. In the File menu, select New Screen Recording.
3. In the Screen Recording window, click on the arrow drop-down menu and select the desired options.
4. Set up the conditions that you want to capture then click the Record button.
5. Select the desired option for recording either a portion of the screen, or the whole screen.
6. When you’re ready to stop recording, click the Stop button in the menubar.
Note: You can also press Command-Control-Escape on the keyboard to stop the recording.
By default, this procedure will work to record your Mac’s primary display but you can also use it to record an alternate display. For more details, see below the jump.
Der Flounder 
Recent Comments