Posted on 10-09-2017 12:56 PM
Jamf will be discontinuing the Jamf Distribution Server (JDS). We know many of you use and rely on the JDS, but in its current state we cannot recommend it. Therefore, Jamf is planning to end of life JDS at the end of 2017 and access to the JDS installer on Jamf Nation has been removed. The decision to discontinue the JDS is due to several key issues:
Jamf has determined that now is the proper time to move forward with new technologies. Jamf will be focusing on making improvements to the Jamf Cloud Distribution Server (JCDS). Our goal is to provide quality products and help to find a solution for anyone using the JDS. There are a number of alternatives and we are ready to assist you in migrating away from the JDS.
Posted on 10-17-2017 05:17 AM
I was reading @brysontyrrell's blog and he posted about a distribution server named Open Distribution Server (ODS):
The Open Distribution Server (ODS) is an open-source package distribution and syncing solution for IT administrators to serve as a potential alternative for the Jamf Distribution Server.
It looks promising and I'll definitely give it a try.
Posted on 10-17-2017 05:48 AM
@a.holley if you already have hardware out in the field that has your packages on it, pivot away from JDS and simply create File Share Distribution points out of them. Yes, you will have to come up with a sync strategy, but that can be accomplished with a launch daemon and a script to run rsync
or one of the many paid sync tools (Resilio Sync for example). Yes, there's the question of immediate (or near so) availability of packages on all of your distro points due to sync schedules, but it isn't the end of the world, and certainly not something that would cause me to want to walk away from the Jamf product.
And if you read @joe.bloom's post again, the very last line says that Jamf is there to help you identify and move to a new solution.
As @martin mentioned, @brysontyrrell has the ODS that he is working on, and presenting on at JNUC. This is an open-source project that we, the community can help mold and shape in a way that we need.
Yes, the discontinuation of the JDS is a big deal, especially for large enterprises with a large distribution of JDS servers, but it is an opportunity to look at new technologies and design something that will work better for our environments.
Posted on 10-17-2017 08:29 AM
If you're able to come to the ODS session at JNUC please do. As Steve said, my intent is to have the community drive where the project needs to go, and there will be many ways to contribute to it that don't involve writing code.
I'll make another post here on JN containing the session details.
Posted on 10-17-2017 11:57 PM
@brysontyrrell given I'm in Australia, and as previously mentioned, working for an NFP, attendance at JNUC isn't happening unfortunately.
Posted on 10-24-2017 09:24 AM
@were.wulff @brysontyrrell
Quick Question - you covered all the in house ebooks and apps and such.
What about scripts? Will they still remain in the database or will there be some function to pull them back out?
If we switch from JDS back to a SMB file share, will the scripts be properly deployed?
I assume this will be less of an issue as DEP really gains ground but for now, how will the Jamf Pro Server handle scripts?
Thanks! And I love the name change, Were!
Posted on 11-12-2017 10:37 AM
Going back to memory... IIRC, the JDS really started to have issues in Sierra 10.12.4 when Server 5.3 was released and TLS 1.0 and 1.1 support went away. So, until @brysontyrrell can get a big launch on "JDS 2.0" AKA "ODS" is released, wouldn't it make sense to rebuild a JDS with OS X 10.12.4 and running Server 5.2 without upgrading to Server 5.3?
The next question would then be... Could we get away with upgrading to JAMF Pro 10.0 and still maintain the legacy JDS instances?
Posted on 11-12-2017 10:58 AM
@jrippy looks like you didn’t get an answer but I’m case you still need one, since JAMF moved the scripts to the database, scripts have never used any DPs for distribution be they SMB, AFP, HTTP, etc. The scripts are downloaded from the JSS directly by the Jamf binary to the local machine and then run directly.
So it’s copied over from the same connection that is pulling down policies, doing recons, etc, so nothing should change.
Posted on 11-20-2017 06:17 PM
@stevewood wrote:
that can be accomplished with a launch daemon and a script to run rsync or one of the many paid sync tools (Resilio Sync for example).
If you're on RHEL (or CentOS, etc.), a one line script is all you need, with a crontab, and RSA keys so no passwords are needed (but still secure).
The technology is native to the OS, so no Reselio marketing department to feed. :)
Maybe over the holidays I'll put together a how-to, with credits to the folks the bits and pieces were stolen from.
Posted on 11-21-2017 01:19 AM
Below is the script we use for DP Syncing instead of Rsync. You need HomeBrew, LFTP, ssh-keygen, ssh-copy-id. Lingon-X (optional) or launch daemon if using Mac Servers. If using Ubuntu or CentOS, I believe LFTP is native.
Good for Large Packages, Split files for faster upload. Continue interrupted transfers.
#!/bin/sh
lftp -u casperrw,pass -e "set sftp:connect-program 'ssh -a -x -T'; mirror -R -v -c --loop --delete --use-cache --log=/var/log/dpsync.log --use-pget-n=10 -P 2 /Volumes/ServerHD/MasterShare/Packages /Volumes/ServerHD/RemoteShare/Packages ; quit" sftp://remote.host.ip:22
Credits
http://www.commandlinefu.com/commands/view/13759/fastest-segmented-parallel-sync-of-a-remote-directory-over-ssh
http://www.thegeekstuff.com/2008/11/3-steps-to-perform-ssh-login-without-password-using-ssh-keygen-ssh-copy-id
https://lftp.yar.ru/lftp-man.html
Posted on 11-21-2017 11:05 AM
@Eigger awesome stuff...can you put the commands into code format by selecting the text and hitting ">_" in the post window, so we can see the command with proper wrapping?
Posted on 11-21-2017 12:01 PM
@donmontalvo I look forward to seeing your how-to.
Over the holiday break I am cleaning up a bash script I built for uploading packages to the parent distro then creating the Jamf Pro entry with API. It uses RSA keys and SCP for the package transfer. and if I can gleam an easier way to move packages and then replicate.. I may owe you a beverage of choice lol
Posted on 11-23-2017 04:06 AM
Like @strider.knh we are also a (Pre)K-12 site in a country where bandwidth is astronomically priced. (We currently pay nearly USD $100k/yr for 65Mbps!) So... NO cloud options are good options! In fact, we just left Adobe CC in favor of Inkscape and GiMP for that very reason.
However, we've become somewhat disillusioned with JAMF. We were promised it would be an all-inclusive package... that we wouldn't need rsync or any other kludgy "solutions". All we needed was Casper. However, what we got is a system which needs to be rebooted nearly every day and we're constantly running SQL queries for the past several months to help "support" to do their jobs. And to top it off, 16 months after installing, it's still not managing even 1 of our iPads.
Frustrated and feeling duped,
Brian
Posted on 11-27-2017 06:16 AM
Hello, I'm Robby from Resilio. Please email me if you have a use case that you think could benefit from an alternative to JDS like Resilio Connect.
Resilio branched off BitTorrent and our Connect software is an enterprise-level distributed file delivery solution that uses peer-to-peer for the most reliable and efficient file replication possible. We can easily arrange a POC for each use case.
Thanks!
-Robby (robby@resilio.com)
Posted on 12-14-2017 11:38 AM
@chriscollins Thanks for the reply.
Actually, my post was to see if Jamf might remove the scripts from the database again.
It still doesn't make sense to me why they would be stored there.
Posted on 12-14-2017 12:03 PM
@jrippy I got to be honest, I think that would be a terrible idea. We have tons of policies that just run scripts. Scripts are so lightweight I don't see the need to mount a file share or connect to another HTTPS server when the script data can be sent along in the same data as the already minimal jamf binary traffic.
Posted on 12-20-2017 07:16 AM
New Guy Here...looks like Content Caching in High Sierra might be the ticket in my environment (just upgraded 9.9.6 > 10.0.0 today).
Unfortunately, I am not privy to the Developer Enterprise Program...a manual hack it shall be!
Easy-ish
If you have Server.app and are actively enrolled in Apple DEP for in-house app/installer package signing
Fun Time
macOS High Sierra: Configure Advanced Content Caching Settings
Posted on 01-12-2018 02:47 PM
I'm wondering if people have migrated from the JDS and which solution they have found. Development on ODST doesn't seem to be very active.
I really liked it that we're able to upload a package via Jamf Pro server web-interface, the ease of deployment and automatic replication. Technically it was a disaster but that's because JDS has never been improved after releasing it.
I don't like the facts that Jamf has removed a part of the solution and doesn't offer an alternative. It's like we are paying more for less. So I'm not looking for a paid solution from a third-party.
Posted on 01-16-2018 04:49 AM
I have been told by JMF that ODST is the only thing they know about.
Posted on 01-30-2018 05:40 AM
I used SMB originally, but moved to JDS 1 or 2 years ago thinking it was the future because of automatic replication, etc.
Removing JDS clients seems like a backwards move?
Posted on 01-30-2018 05:52 AM
This was the only feature JAMF had that kept us using there products. Now we will have to switch to a competitor.
Posted on 02-05-2018 11:30 AM
We rely heavily on JDS and are stuck on 9.96 until we change to FSDP. I'm testing SMB shares right now, should I enable HTTP downloads? With Apple stripping away Apache in the upcoming Server app, will Apache have to be reinstalled manually?
Posted on 02-05-2018 11:42 AM
I'd recommend getting in touch with your Support rep to go over your environment, what you'll need, and some options for what can be set up to make that happen. There are options aside from Apple's Server.app for setting up SMB shares and for using HTTP; many customers use some flavor of Linux to make that happen, or they use a Windows server. If what you're looking for is an SMB share with HTTP capabilities, Support can go over what you have as well as give you advice on potential alternate setups if what Apple currently has (or won't have in the future) may present issues down the road
While I'm sure you'll also get some advice here that'll be helpful, with Support being able to dig more into the details of your unique environment, they may be able to help get a good plan tailored with a bit more detail.
Thanks!
Were Wulff
Jamf Customer Experience
Posted on 03-12-2018 09:27 AM
@Lotusshaney Are you running Syncthing on Mac or another platform? If Mac, do you have it running pre-login? I installed Syncthing via Homebrew and it only launches at Login, and then quits at Logout. On a headless Mac Mini I want to have it running at boot without anyone logged in.
Posted on 04-09-2018 10:18 AM
If you are still looking for a DP Synchronization solution. Please check this out [https://github.com/userdocs/lftp-windows](link URL)
This is a really nice tool. If you have V Sphere/Windows environment. Its using WinSCP and LFTP (Excellent for Segmented Upload/Download). Can be automated using Task Scheduler with Push Notification. And its FREE!
Posted on 04-09-2018 10:20 AM
I cannot say enough good things about our 250+ DP Windows DFS based replication scheme!
Posted on 04-09-2018 10:35 AM
Posted on 07-03-2018 07:59 AM
Greetings everyone,
I have an important update for you on the Jamf Distribution Server (JDS). As noted in the original post, we marked the JDS as being "end of life" at the end of 2017. We have been slow in our process of officially removing it from Jamf Pro in order to provide time to migrate to another software distribution method.
I can now confirm that in our upcoming 10.6 Jamf Pro release, the JDS will no longer function. Please be sure that you have another solution in place before moving to the 10.6 release. That release is in beta right now, and I expect it to be available in the next three to four weeks.