Viewing entries tagged
terminal

macOS Network Shares with Permission Inheritance

2 Comments

macOS Network Shares with Permission Inheritance

Creating a network share on macOS does not automatically propagate assigned permissions to child files & subdirectories. This means if one user creates a new directory in a share, other users are able to view the new directory, but are unable to add anything to it. Correctly configuring directory permissions is the solution covered in today's blog post.

Understanding File & Directory Permissions

POSIX permissions are used to assign basic read, write and execute privileges to the owner (creator of the file/directory), group (a single group inherited from the parent directory) and others (everyone else).

At the same time an access control list (ACL) can be applied to a file/directory to assign specific permissions, allowing for multiple users and groups with varying levels of access. ACLs override POSIX permissions and are comprised of access control entries (ACEs), each entry specifying a particular user or group's rights (either an allow or deny) to perform specific operations. The ACEs in an ACL are evaluated from top to bottom until an ACE that applies to the user is found, once a match is found all remaining entries are ignored, making the order of ACEs paramount.

To allow our users to add to each others directories we simply add the file_inherit & directory_inherit attributes to an ACE. This will ensure the ACL applied to the share is inherited by child files & subdirectories.

There are two ways to apply an ACL:

Server app

Select the server name in the left sidebar, click the Storage tab and drill down to the directory you wish to modify. Click the gear at the bottom of the screen and select "Edit Permissions..." Expand out assigned users & groups, tick Inheritance and click OK.

Doing so will apply the ACL to the selected directory, but not to any subdirectories. If you wish to apply the same ACL to subdirectories, select the gear again, then 'Propagate Permissions...' and with only the Access Control List checkbox ticked click OK.

Note: You will notice inherited permissions are greyed out in the Server app to prevent accidental editing.

Terminal

Those comfortable in Terminal may wish to do the same via the command line.

List

To list existing ACLs in a directory:

ls -le

Add

To recursively add inheritance to a directory simply append  file_inherit & directory_inherit tasks to the end of the existing ACE:

# Recursively add the following ACE to all files and folders inside Directory Name, marking the ACE as inherited.
chmod -R +ai "group:marketing allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,file_inherit,directory_inherit" "Directory Name"/*

# Apply the same ACE directly to "Directory Name," without marking it as inherited (allowing it to be edited in the Server app).
chmod +a "group:marketing allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,file_inherit,directory_inherit" "Directory Name"

Insert

Use +a# to insert an ACE at a specific index (at index 0):

chmod +a# 0 "group:marketing allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,file_inherit,directory_inherit" "Directory Name"

Replace

Use =a# to edit an existing ACE (at index 2):

chmod =a# 2 "group:marketing allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,file_inherit,directory_inherit" "Directory Name"

Remove 

Use -a# to remove the first ACE (at index 0):

chmod -a# 0 "Directory Name"

Use -N to alltogether remove an ACL from a file or directory:

chmod -N "Directory Name"
# Tip: chmod -RN will recursively remove ACLs

Further Reading

If you would like to learn more about macOS file permissions the following are great resources:

2 Comments

Printing Hierarchical Directory Structures in Terminal

1 Comment

Printing Hierarchical Directory Structures in Terminal

Tree is an open source command line tool for recursively outputting the structure of a directory. It is useful for generating a clear representation of complex directory structures.

Installation

Tree is compatible with most Unix based operating systems, including macOS. Since tree is not included with macOS, here are two methods for installing it:

Via Homebrew

If you already have Homebrew installed simply run:

brew install tree

From Source Code

1. Download the source code from GitHub:

git clone https://github.com/execjosh/tree.git

2. Move into the tree directory and edit the Makefile:

cd tree
nano Makefile

3. Comment out (prepend a #) the line under Linux defaults and uncomment (remove the #) the lines under the OS X section:

 

Note: To save changes in nano; press control + X, then Y and return.

4. To compile the binary simply run:

make

5. Move the newly generated binary into /usr/local/bin/:

sudo mv tree /usr/local/bin/

6. Lastly, move the manual page into /usr/share/man/man1/.

sudo mv doc/tree.1 /usr/share/man/man1/

Usage

Tree has many options and the manual page goes into each one in-depth, you can view the man page with:

man tree

Our favourite options:

  • -C: Colour folder names to help distinguish files from folders
  • -d: Only output directories, not files
  • -H: Output as HTML with hyperlinks to files and folders
  • -N: Do not escape spaces with forward slashes or replace non=printable characters
  • -o: Send output to a file
  • -Q: Put double quotes around filenames

Example

Using tree to list all files and folders in a user's Music directory:

 

1 Comment

Raspberry Pi Tips & Tricks

Comment

Raspberry Pi Tips & Tricks

Introduction

For those unfamiliar, a Raspberry Pi is a low-cost, energy efficient, highly extensible, credit card sized computer. To assist new Raspberry Pi owners I have put together my notes on the topic and will continue to append to it as new discoveries are made.

Common Commands

Copying a Raspberry Pi Operating System Image (.img) to a microSD Card

Loading an initial operating system can seem like a daunting task, in fact many Mac users are unaware that copying an .img file to a microSD does not require any additional software. In this example I will be using Raspbian Stretch Lite, a good base image for most Raspberry Pi projects.

Connect the microSD card to a Mac using an SD card adapter or a microSD to USB reader.

To find the disk identifier of the microSD card, open Terminal and run the following command:

diskutil list

In my situation the microSD was mounted as /dev/disk2, I could tell this by comparing the size of the disk (31.1 GB).

 

Before we can copy the Raspbian data to the microSD card we need to unmount the disk first with the command:

sudo diskutil unmountDisk /dev/disk2

Time to copy the contents of the image file to the microSD card, take note of the r in front of disk2:

sudo dd if=~/Downloads/2017-11-29-raspbian-stretch-lite.img of=/dev/rdisk2 bs=1m

Setting Up a Headless (No Screen) Raspberry Pi

By default SSH (remote login) is disabled. To enable SSH create an empty file called "ssh" in the root of the SD card. On a Mac this can be achieved with the Terminal command:

touch /Volumes/boot/ssh

Connect to Wi-Fi

Raspbian includes the Raspberry Pi Software Configuration Tool, this includes a user friendly way to configure network settings. To open type:

sudo raspi-config

If you are unable to run the above command (e.g. no display or Ethernet available) and want the Raspberry Pi to connect to Wi-Fi, create a wpa_supplicant.conf file in the root of the SD card (/Volumes/boot/) and add the following:

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=AU

network={
    ssid="Your Wi-Fi network name"
    psk="Your Wi-Fi password"
    key_mgmt=WPA-PSK
}

Changing the Default User Password

By default the username is pi and the password raspberry. Once logged into the Raspberry Pi, the easiest way to change the password is with the command:

sudo raspi-config

Updating Raspbian

To check for and install any available updates:

sudo apt-get update && sudo apt-get dist-upgrade && sudo reboot now

Favourite Use Cases

Pi-hole - Block Ads On Your Local Network

Pi-hole is one of the best uses of the Raspberry Pi hardware. Pi-hole acts as a Domain Name System (DNS) server on the local network, blocking requests to ad related networks. This results in webpages and apps displaying content without unwanted ads. The screenshots below show the difference Pi-hole makes to the website speedtest.net.

Pi-hole also includes a nice dashboard, reporting usage and providing the ability to further blacklist/whitelist specific sites.

Digital Signage

Screenly & Yodeck have Raspberry Pi software allowing any TV to be used for digital signage. Updating what is displayed on screens is as easy as uploading new content via a web browser. Both currently offer a free tier for a single display.

Comment

Installing & Automating AutoPkg with a Launch Daemon

2 Comments

Installing & Automating AutoPkg with a Launch Daemon

UPDATE (1/12/15): Since AutoPkgr now supports recipe overrides I recommend using AutoPkgr over my headless script.


AutoPkg is a great tool for downloading and packaging software for distribution. It also integrates nicely with Munki. After testing AutoPkg I looked into methods to further automate the updating process. I came across Sean Kaiser’s blog detailing how he created a script and triggered it using a launch daemon. I took his script as an example and began to build my own, with a few extra tweaks.

My AutoPkg Wrapper triggers AutoPkg to run once daily at 8:30am, dynamically checking for updates to user recipe overrides and sending an email in the event of a new package.

Without further ado I will walk you through setting up AutoPkg and automating it with my AutoPkg Wrapper.

Note: If you haven’t already, it is important to install Munki and AutoPkg.

 

Configuring AutoPkg

First we need to add the main recipe repository to AutoPkg, we do this by opening Terminal and typing:

autopkg repo-add http://github.com/autopkg/recipes.git

Note: AutoPkg requires Git to be installed, if it is not installed you will be prompted to install it from Apple Software Update.

Next we need to set the location of our Munki repository:

defaults write com.github.autopkg MUNKI_REPO "/PATH/TO/MUNKI_REPO"

AutoPkg uses recipe overrides to override default or unspecified recipe attributes. My Munki repositories follow a consistent naming convention and therefore I create recipe overrides for every AutoPkg recipe used. Below are the criteria for packages added to my Munki repositories:

  • Packages are placed directly into pkgs and not into subdirectories.
  • Packages are named in lowercase (e.g. Firefox.dmg > firefox.dmg).
  • Packages do not contain the developer’s name (e.g. googlechrome.dmg > chrome.dmg).
  • Packages are initially added to the development catalog.
  • The pkginfo display_name attribute is set to match the package name with proper case and spaces (e.g. flashplayer.dmg > Flash Player).
  • The unattended_installs pkginfo attribute is disabled.
  • The developer and category pkginfo attributes are set.

 

Optionally you can download and install my collection of AutoPkg recipe overrides from GitHub:

git clone https://github.com/Error-freeIT/AutoPkg-Recipe-Overrides.git ~/Library/AutoPkg/RecipeOverrides

 

With AutoPkg configured let’s test a recipe:

autopkg run -v AdobeFlashPlayer.munki

Automating AutoPkg

If that worked it’s time to automate AutoPkg, download and run the autopkgwrapper installer:

git clone https://github.com/Error-freeIT/AutoPkg-Wrapper.git /tmp/autopkgwrapper && cd /tmp/autopkgwrapper && sudo ./install.sh

The install script requires administrator privileges and therefore will prompt for a password, as it copies the script and launch daemon into place and opens the script in Nano for configuration.

Update the ACCOUNT_NAME value to match the account name (a.k.a. username) containing the recipe overrides and update the EMAIL_FROM and EMAIL_TO addresses.

Note: To save changes in the Nano text editor press control + X, type y and hit return.

That’s it! Once set up you will be emailed when new items are added to the Munki repository. Standard workflow would then involve testing the new software and if the new software is stable, simply add it to your production catalog.

 

Troubleshooting The AutoPkg Wrapper

This AutoPkg Wrapper was intended to only be run as a launch daemon (by root) to manually run the AutoPkg Wrapper type:

sudo "/Library/Scripts/AutoPkg Wrapper/autopkgwrapper.sh"

You can update your email settings by typing:

sudo nano "/Library/Scripts/AutoPkg Wrapper/autopkgwrapper.sh"

By default the installed launch daemon is set to run daily at 8:30am, if you want to further customise how often the script is run I recommend editing the launch daemon with Lingon X.

2 Comments