Closed georgekarrv closed 6 months ago
Hey team! Please add your planning poker estimate with Zenhub @dantecatalfamo @ghernandez345 @gillespi314 @jahzielv @mna @roperzh
@mna @ghernandez345 one thing I want to note that might help, the nano queue has a priority
field:
that might come in handy to achieve the order specified in the issue:
@roperzh Just to sanity-check my understanding with you for that priority
approach, as I don't think I grasp the nanomdm's flow as well as you:
priority DESC
, but it skips any non-NULL result status (and possibly NotNow
ones too)If that's the case (that only NotNow
is a problem), I think we could relatively easily handle this case by not returning the next command when we receive a NotNow and there is at least one command available with a priority > 0. Unless of course we want to release the device only after osquery verification, but I don't think that's the case?
@mna what you described is exactly my understanding!
nanomdm does not store "Idle" statuses
to add more color to this, in case it helps. Idle
is how the device starts the MDM session, so it's never a "result" of another command.
Do we retry commands that result in errors? If not, then this is a final state and I think the only problematic status (that could mess the ordering) would be "NotNow"?
currently we don't! we do retry things (eg: failed profiles) but we use a new command to retry those, so I think what you described is exactly right.
If that's the case (that only NotNow is a problem), I think we could relatively easily handle this case by not returning the next command when we receive a NotNow and there is at least one command available with a priority > 0. Unless of course we want to release the device only after osquery verification, but I don't think that's the case?
this sounds reasonable to me. I'm not sure if this is a problem, but the only danger I see with using priority
is that every time we enqueue a command, we also send a push notification to the device.
if we don't enqueue all the commands we need delivered in order in the same transaction, then the device could reach out and get commands out of order (if that makes sense)
@roperzh
the only danger I see with using priority is that every time we enqueue a command, we also send a push notification to the device. if we don't enqueue all the commands we need delivered in order in the same transaction, then the device could reach out and get commands out of order (if that makes sense)
Ah right, good call... That's going to be a problem.
@mna that one is tricky... spitballing anything that comes to mind, in case any of this helps:
priority
, there's also the active
, I wonder if we could enqueue all the commands as active = 0
and switch them to 1
when we know we're ready? (seems a bit sketchy?)AccountConfiguration
to be sent (so the username and fullname are pre-filled)@roperzh thanks for helping thinking this through, I know you're super busy with high-priority work too, I appreciate it! Did a bit more digging and it looks like all DEP commands get sent here: https://github.com/fleetdm/fleet/blob/61544f4beacb21570ef4cffbfa29c199fb8b491d/server/worker/apple_mdm.go#L83
So I think it would be doable to send them all in one transaction with the relevant priorities in this scenario. Only thing it wouldn't cover, and I'm not sure how easily we could, is the delivery of profiles - I assume those are profiles for the team the host enrolls in? And those run in the ReconcileAppleProfiles
job so it's async and runs every 30s. (maybe by enqueuing another worker job to run later, and hope that by then - and with the help of some retries - all profiles have been delivered)
I'll try to go down that route, let me know if you see any concerns/blockers with it but otherwise I'll try to leave you alone! :D
In the cloud city, Fleet eases Mac setup steps, Devices freed, users rest.
MacosSetupAssistantUpdateAllProfiles
worker job which will re-register all existing DEP profiles withawait_device_configured
totrue
[x] From the Slack convo with Noah, we should test this scenario
The device is blocked on a screen until released.