https://github.com/hobadee/jamfvault
Syncs Jamf objects to disk so you can version them with GIT
https://github.com/hobadee/jamfvault
jamf jamf-pro jamf-pro-api jamfpro sync
Last synced: 3 months ago
JSON representation
Syncs Jamf objects to disk so you can version them with GIT
- Host: GitHub
- URL: https://github.com/hobadee/jamfvault
- Owner: Hobadee
- License: mit
- Created: 2024-05-23T19:33:07.000Z (over 1 year ago)
- Default Branch: main
- Last Pushed: 2024-10-16T07:22:45.000Z (12 months ago)
- Last Synced: 2025-04-11T08:38:56.997Z (6 months ago)
- Topics: jamf, jamf-pro, jamf-pro-api, jamfpro, sync
- Language: Python
- Homepage:
- Size: 65.4 KB
- Stars: 3
- Watchers: 1
- Forks: 0
- Open Issues: 7
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# JamfVault
This project helps sync Jamf items to a local repo, so they can be controlled with source-control, rather than in the Jamf UI without and SCM.
The end-goal of this project is to allow any push to a repository managing Jamf scripts (or other supported objects) to automatically update Jamf.
Currently this project is very basic. It will only allow syncing of scripts, and must be run manually. It should be fairly trivial to make a
CI/CD worker which calls this, but that's a task for later.
# TODO
[x] Support syncing Scripts to/from Jamf
[ ] 100% unit-testing coverage
[ ] Support syncing Computer Extension Attributes (Particularly, the scripts of scripted EAs)
[ ] Possibly support syncing Policies
[ ] Possibly support syncing Profiles
[ ] Possibly Support syncing Device/User Extension Attributes
# Repository Organization
The organization of this project isn't great right now. Re-organization is likely.
# Testing
While a few unit-tests currently exist, and did help some for development, test coverage is terrible. It needs to be greatly improved.
# Design
1. Each Jamf itme has an underlying object to describe/store it
2. An abstract strategy pattern is used to either `load()` or `save()` the object
3. Concrete strategy patterns implement `load()`ing or `save()`ing to Jamf, Disk, or whatever other endpoints we decide to add.
We still deal entirely with objects here
4. A Facade for each endpoint handles direct communication with the underlying system, such as Jamf or Disk.
These facades handle all conversion to/from objects and are the delineation between objects and APIs/Disk access
# Syncing
Since Jamf has a flat strucutre, but repos often have folders, the syncing should handle this gracefully. As such, we will loop through directories
to find what we need. We match based on name. Even though names in Jamf and Disk names can be changed, we use these as the Primary Key, so to speak,
and do most of our matching off the name rather than the ID Jamf gives us. (If an ID were to change on Disk accidentally and sync to Jamf, it could
have disasterous consequences. Changing a name is much less likely to end in tragedy.)
A note on syncing - while syncing *WILL* overwrite existing items, syncing will *NOT* currently delete items missing from one side or the other. If we
decide to implement this in the future, it will probably be a new Strategy method. (Such as `prune()` or something)
## Folders
When you sync, you will need to specify a root folder for the Disk Strategy. Under this root folder, several additional folders will be used:
### `scripts/` subdirectory
The `scripts/` subdirectory will be used for syncing Scripts. Any file in here that ends with `.sh` or `.py` will be elegible for syncing.
Scripts synced from Jamf to Disk will be placed in additional subdirectories according to their Category.
** IMPORTANT: ** Every Script must have a matching `.json` file that includes other Jamf settings. Here is a minimal example:
``` JSON
{
"categoryId": -1,
"categoryName": "NONE",
"info": "",
"notes": "",
"osRequirements": "",
"parameter10": "",
"parameter11": "",
"parameter4": "",
"parameter5": "",
"parameter6": "",
"parameter7": "",
"parameter8": "",
"parameter9": "",
"priority": "AFTER"
}
```
Currently there is only very basic type-checking of the fields, so incorrect values for fields like "priority" are likely to cause issues.
Optionally, a matching Markdown (`.md`) file may be included with notes, todos, or other information about the script. Currently, nothing is done with
this file, but it is possible we do something with it in the future. (We may decide to read this into the "Notes" field, for example.)
### Other subdirectories
As additional Jamf modules are included, subdirectories for each module will be added.
# Examples
Please see the `example.py` file