Current state of block copy from JDS using Casper Imaging/NetBoot?

Hello @stevehahn,

I went through several weeks of extensive troubleshooting regarding imaging via JDS using block copy and what I ended up finding resolving it for me was a change in permissions. The Casper Imaging debug log showed me that it was hinting toward a permission-related failure, so I logged into my JDS (Linux based) and navigated to /usr/local/jds/shares/CasperShare/ and checked the permissions on the contents. I found that the particular DMG in question did not have the same permissions as the rest of the files. I ran the command below to make every file the same and tested imaging again and it worked. I hope this helps!

cd /usr/local/jds/shares/CasperShare/
sudo chmod 644 *.* && sudo chown -R root *.* && sudo chgrp -R root *.*

Hey @stevehahn

In addition to @cstout ’s info, if that doesn’t work, we can try expanding the NetBoot image size.

To stretch a NetBoot image:

1. On the server, open up a terminal window.
2. Type: sudo hdiutil resize -size 15g /path/to/image/file (Usually something like: /Library/NetBoot/NetBootSP0/ImageName.nbi/System.dmg)

NOTE: 15g is simply an example; if yours is already that large, try 20g or something higher. It can take quite awhile for the process to finish, when it’s done it’ll just drop you back to a terminal prompt.

Let us know if either of those methods takes care of the issue.

Thanks!
Amanda Wulff
JAMF Software Support

@stevehahn

We had the same issue, but once we did the steps that @amanda.wulff pointed out (as well as the diskless booting guide), everything worked much better.

Does that actually make the NetBoot.dmg that large, or does it grow to that size on mount?

@bentoms, it actually expands the size of the DMG. My netboot.dmg is now 21GB

Thanks. Is this needed for JDS then?

I don't do that with our current AFP Casper Shares.

@bentoms This issue does appear to be only when using NetBoot and connecting to a JDS. In my testing I had no issues with File Share distribution points.

Thanks. May impact a little something I'm doing.

I'll reply here when done, maybe you can test this project for me?

@bentoms @cstout

The only time we should need to do it is if we're finding that the JDS, when NetBoot imaging is just flying by the block copy without actually doing the block copy.

It's specific to the JDS being the primary DP when using NetBoot for imaging.

If the JDS is working fine for NetBoot purposes, it shouldn't need to be done.

We had it filed as an open defect for awhile (D-005796), but it was canceled and closed after we found that all we needed to do to make it work was expand the size of the NetBoot image with hdiutil.

Thanks @amanda.wulff.. That's a shame :(

Oh we'll more to add to my project.

@amanda.wulff, so when JDS is primary DP & used for imaging?

So like the master DP? Does it affect child JDS?

@bentoms

Reading back over the old defect, it looks as though the following two things have to be true to reproduce the behavior:

- The JDS must be designated the master distribution point.
- We must be imaging via NetBoot.

If both of those things are true, we see that block copy fail until we increase the size of the NetBoot image.

It doesn't seem to do the same thing if the master DP is a standard file share and there are child JDSes, as it will mount the actual file share first.

Semi-related to this topic (JDSes vs. Imaging), we do still have a currently open defect (D-006157) in which, if a JDS is designated the default distribution point for a network segment, Imaging (in any form, TMI, running locally, NetBoot) does not respect the segment's default distribution point and will default to the master distribution point which may or may not be the JDS designated.

This can result in a few scenarios that could cause undesired behavior:

1. If a JDS is the master distribution point but the JDS specified in the Network Segment is a different JDS, the default distribution point in Imaging will be the master JDS. This is NOT expected behavior, and is part of the defect.

2. If a File share distribution point is the master, and a JDS is specified in the Network Segment, Imaging will default to the master File share distribution point. This is NOT expected behavior, and is part of the defect.

3. If a JDS is the master and the distribution point specified in the Network Segment is a File share distribution point, the settings in the Network Segment are respected. This is expected behavior.

4. If a File share distribution point is the master but a different File share distribution point is specified in the Network Segment, the settings in the Network Segment are respected. This is expected behavior.

Right, so only resize if master DP is JDS?

Meh, JDS looks like a mess especially for us with macs globally deployed with local DP's & non-Casper literate techs doing the imaging.

@bentoms

Right.

If yours is working as is with the file share as the master DP, there's no need to change anything with it.

If you do start testing with a JDS as the primary, test it out with your NetBoot image as-is first and see if it works; if it does, no need to tweak anything. If it doesn't, we can see if the steps in this thread take care of it.

@bentoms, I was hooked on the potential and automation of the JDS and ran into issue after issue. It's in a rough place right now, but as soon as these bugs get hammered out I really do think it will be a superb addition to the Casper Suite. In the meantime, I've kept my two JDS's up and running and switched back to distribution shares while waiting for future releases.

@amanda.wulff, thanks.

FWIW, I'm working on something called: AutoCasperNBI.

I was going to add an option to import the JSS CA if using a JDS, I think I'll grey it out until the defects are resolved.

Right, I'm off to tinker some more.

@cstout, yea I think we'll keep waiting.

Especially as we're multi-national, bandwidth is at a premium.

So can't have people imaging from sources across the MPLS nor can we use the JDS without being able to schedule replication. (I've filed an FR for that one).

@bentoms, is your FR for scheduling replication the one titled, "Staging failover & replication of distribution points."?

@cstout, it's not that one, but another FR of mine: https://jamfnation.jamfsoftware.com/featureRequest.html?id=2177

@bentoms, thanks! There's my vote. Instant replication for small files isn't a huge deal for our WAN link here, but I'd love the ability to schedule replication when I've updated a base image or some large software suite.

Hi @cstout and @amanda.wulff, thanks for your suggestions. My JDS is on a Mac and so the owner and group are _www:staff rather than root:root, but I modified the command accordingly--unfortunately no help there. I also had already tried growing the dmg while on a call with my support rep, also to no avail. I suppose it's possible I messed something up while building my NBI; I might just try rebuilding it from scratch and see what I get.

We are having the same problem with our JDSes. We have tried to grow our images without any luck. We even downloaded the JSS Built-IN CA to our NetBoot computer and that did not help either. It was already there, but we replaced it anyway. It did not change anything. Our rep thinks it might have to do with the JDS and possibly certificates. Our permissions on our JDS CasperShare are the same as yours. He looked at the certificates we had on our JDS and we only had the self-signed root certificate. The server we was using at JAMF had different certificates. Not sure if this is the problem. Waiting to hear back from JAMF.

@bstrube

He looked at the certificates we had on our JDS and we only had the self-signed root certificate. The server we was using at JAMF had different certificates. Not sure if this is the problem.

It may not be the only issue, but it certainly could cause problems if the JSS is using a third party SSL certificate. Typically, we do need to have the root and intermediate CAs imported to the JDS as well as the CA from the JSS (either its built-in or a third party, whichever your environment is using). If your JSS is using a third party certificate, that will also need to be imported into the JDS' certificate store, though those not being there typically won't cause 'unable to connect' errors; when it's a certificates issue we usually see errors that specifically mention problems with a certificate.

One thing that comes to mind, off the top of my head: Do you have Enable Certificate Based Communication checked on your Master JDS (or any of your JDSes, for that matter)?

We can check by going to Computer Management >> JDS Instances >> Select the instance we want to check >> Distribution.

If that box is checked, it's possible you're running into D-006853 or D-007005. In both cases, the workaround is to uncheck “Enable Certificate Based Communication” for the JDS. The symptoms we see with those defects are Casper Admin being unable to mount the JDS or packages being unable to be downloaded from the server with an error similar to "Error: Could not connect to the HTTP server to download $PackageName."

Amanda Wulff
JAMF Software Support

We do not have "Enable Certificate Based Communication" checked on any of our JDSes. We are using the JSS Built-In CA on the JSS and it is in the System Keychain of the machine we are NetBooting from. It is like it is cannot mount the CasperShareDAV on the JDS.

@bstrube][/url

Well, that rules out the 'easy fix' option there, I guess!

Outside of a NetBoot environment, are your JDSes working as expected?

I see that you mentioned that you did try growing the image file with sudo hdiutil resize; how large did we expand it?

When I redid one of mine, I had to kick it up to 25GB (sudo hdiutil resize -size 25g /path/to/image/file) to make it work with my JDS. The original size had been 10GB, and I'd tried it at 15 and 20 with no luck.

Amanda Wulff
JAMF Software Support