Populating Your Local Repository

Populating Your Local Repository

Fetching Existing Resources

If you already have resources in Iru, you can have iructl pull all or some of them down to your local repository with a single command. Use the --all option to pull all of a resource type into the local repo or select specific resources with the --id option. --id can be specified more than once to include multiple resources.

• iructl profile pull [OPTIONS]
• iructl script pull [OPTIONS]
• iructl app pull [OPTIONS]

This will create a profiles, scripts, or apps directory in your repository, if one doesn't exist, and download each Iru resource and its metadata into a subdirectory.

Note

For apps, iructl app pull downloads metadata only. Add --download to also fetch each app's installer into the payload directory (default <repo>/payloads). A local installer that differs from the one in Iru is left in place unless --force is given. See Working with App Installers for details.

The pull command can also be used to update existing resources with changes from your Iru tenant or to delete resources that no longer exist. By default, nothing is deleted and only resources without local updates are pulled. This behavior can be modified by passing --force (to overwrite local changes) or --clean (to delete local resources which are not present in Iru).

Note

The --clean option can only be used with --all. If you would like to delete only specific resources use the delete command.

If you would like to see what would happen (without making any changes), you can use the --dry-run flag. This will print a full list of actions which would have occurred.

Create a New Resource

The simplest means of creating a new local profile, script, or app is using the new command.

• iructl profile new [OPTIONS]
• iructl script new [OPTIONS]
• iructl app new --file PATH [OPTIONS]

Without any options, this will create a new resource in the respective directory and populate it with default metadata and content. The defaults match Iru's defaults for creating a new profile, script, or app in the user interface (where possible). It's generally recommended to at least specify a name (via the --name option) since the resource directory is named accordingly. Other options can be included to modify the default settings. For a full list of options, see the --help message for each new command.

Tip

You can rename or move a resource's directory anywhere within the main profiles/scripts/apps subdirectories you see fit without affecting the resource. The resource's name is determined by the name key in the info file.

Unlike profiles and scripts, iructl app new requires an installer to import via --file (a .pkg, .zip, or .dmg). The install type is auto-detected from the file extension and can be overridden with --installer-type. The installer is imported into the payload directory and referenced from the app's info file. Use --enforcement to set the install enforcement (install_once, continuously_enforce, or no_enforcement), and the Self Service options to publish it. The optional --import-audit, --import-preinstall, and --import-postinstall options attach scripts (an audit script requires --enforcement continuously_enforce).

Examples:

iructl profile new --name "My Profile" --runs-on mac --active

iructl script new --name "My Script" --execution-frequency every_15_min --include-remediation

iructl app new --file /path/to/MyApp.pkg --name "My App" --enforcement install_once

Import an Existing Local Script or Profile

If you already have a mobileconfig or a script you want to deploy in Iru, you can import the content into a new resource instead of creating one from scratch. For profiles, use the --import option to specify the path to the mobileconfig file. For scripts, use the --import-audit or --import-remediation options. These options can be used with other new command options to specify additional metadata.

Examples:

iructl profile new --import /path/to/MyProfile.mobileconfig

iructl script new --name "My Script" --import-audit /path/to/audit.sh --import-remediation /path/to/remediation.sh

Working with App Installers

An app's installer (a .pkg, .zip, or .dmg) is not stored inside the app's resource directory. Instead, the info file holds only a reference to it (file.name and file.sha256), and the binary itself lives in the payload directory (payloads) at the root of your repository by default. You can point to a different directory with the --payload-dir option or the IRUCTL_PAYLOAD_DIR environment variable.

Important

Iru Control intentionally avoids committing installer binaries to git. When iructl writes to the payload directory it adds a payloads/.gitignore containing * so the binaries are never committed. Otherwise, you are free to manage installers however you wish; they are only required for push operations, which create or update the installer's SHA256 hash in Iru. You can fetch them from Iru at any time with iructl app pull --download or iructl app download. If iructl finds installer binaries already tracked in git, it leaves them in place and warns you so you can untrack them with git rm --cached.

Because the binary lives outside the resource directory, iructl provides two app-specific commands for managing it:

• iructl app download APP: download a single app's installer from Iru into the payload directory. The APP argument is the app's ID or path. Pass --force to overwrite a local installer that differs from the one in Iru.
• iructl app set-file APP --file <path-or-name>: point an app at a different installer, importing it into the payload directory when needed. --file accepts either a path to import or the name of a file already in the payload directory. Use --copy (default) or --move to control how an imported installer is brought into the repository.

Examples:

iructl app download "apps/My App"

iructl app set-file "apps/My App" --file /path/to/MyApp-2.0.pkg