Automating replication to JamfCloud distribution point

If JAMF are nice enough to give you a key for your S3 bucket then you can script it.

I personally use s3cmd for this very thing (but personally hosted S3 bucket).

@pmcgurn

Because Casper Admin uses tokens on the backend for the JamfCloud Distribution Point that users do not have and are not given access to for multiple security reasons, replication must be done through Casper Admin to the JCDS.

There is currently no way to automate replication to the JCDS, but feel free to make a Feature Request if you wish.

Thanks,
Amanda Wulff
Jamf Support

IMHO Jamf should have provided replication automation functionality out of the box using rsync or robocopy for on prem A LONG TIME AGO. No one should be surprised that this has been needed and will probably continue to be needed...

My rsync setup is scaling pretty well, though each DP is a slightly manual setup.

I've automated:
1. Creating the RO and RW user accounts. Bash script to create, Casper polity to securely set passwords.
2. Creating the local share, and setting appropriate permissions on it (bash script)
3. Generate SSH keypair for rsync, set permissions on files/folders (bash script)
4. Create local launchagent that runs an script for rsync every 6 hours from each DP (Composer package with plist for LaunchAgent and script file that it runs)
5. Enable ARD and disable system sleep/HDD sleep
6. Install Master DP's public key in "known_hosts" so first SSH doesn't nag to accept it (Deployed via Composer package)

Still manual:
1. Installing public key on Master DP's authorized_keys file (I can't think of a secure way to do this without having credentials hardcoded in a script.
2. Create DP entry in JSS (I know this is possible with API, but not sure on how to do it without hardcoding creds in a script).
3. Load launchagent for the first time (A reboot would, but I like to confirm it works first).

JAMF was pretty short-sighted on a couple of things:
1. Our sales rep told us to steer clear of JDS, which "should" automate all of this. That was 18 months ago, and nothings changed.
2. Lack of programmatic trigger on JCDS is a clear lack of automation planning on their part. 3. Pushing large packages (OS images, Office) to JCDS is currently broken, known bug, not fixed until JSS 10. This means that, on top of having to manually replicate content, I also have to manually add each package to the sync list and avoid synching large ones to work around it.
4. JCDS can't be configured as a failover/backup DP. So our options are "single point of failure", "build the above with redundancy in each office", or "blast content over the WAN/VPN".

@amanda.wulff Yes, I will be putting idea submissions in, but some of the above is either already there, or supposedly already supported with features (JDS) that aren't maintained in a way that an enterprise should feel can they confidently rely on.

@pmcgurn

1. Our sales rep told us to steer clear of JDS, which "should" automate all of this. That was 18 months ago, and nothings changed.

I'm not sure what your sales rep told you, but they may have been partially incorrect; the JDS can automate replication, but only between other child JDSes. It cannot, does not, and was not designed to automatically replicate between a JDS and an AFP or SMB share. Replication to/from a JDS and a file share still must be done manually through Casper Admin.

The JDS is currently able to automatically replicate between the master and child JDS/JDSes. It has been able to do that since its initial release.

I mention this simply because we've seen some ongoing confusion about the JDS and what it can do automatic replication wise.

It's likely that they told you to steer clear of it as there are several outstanding PIs open for the JDS that can render it randomly unusable, or that cause it to break after running an upgrade even if the upgrade reports that it's successful. We see this more often on OS X JDSes, but it can happen on Linux JDSes as well.
Development is currently working on an overhaul to to the JDS to address its outstanding issues, but we do not have an ETA on that.

4. JCDS can't be configured as a failover/backup DP.

Currently, no cloud distribution point (AWS, JCDS, Rackspace, or Akamai) can be used as a failover, so that is not specific to the JCDS; there is a feature request to address that issue here.

There is one for adding the JDS as a failover here.

Thanks!
Amanda Wulff
Jamf Software Support

Our sales rep told us to steer clear of JDS due to the random instability. My requirements for a DP are:

1. It works reliably
2. It's easy to administer

For lack of 2, I default to 1. For lack of 1, I seek an alternative solution.