Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CDP DP Type #22

Closed
sheagcraig opened this issue Dec 10, 2014 · 2 comments
Closed

CDP DP Type #22

sheagcraig opened this issue Dec 10, 2014 · 2 comments

Comments

@sheagcraig
Copy link
Collaborator

As per lindegroup/autopkgr#172

@sheagcraig
Copy link
Collaborator Author

@luisgiraldo

Alright! Let's get this working.

So bear with me on this: the way that JDS' work is that you actually upload a file to the JSS. The JSS puts it in a special holding area for new uploads. Periodically the JDS' will check in, much like a regular computer has a policy check-in. The JDS will see the new package or script and sync it to its configured storage.

My guess is that the CDPs work the same way. I think it probably has to be this way, since you could have a mix of traditional file share DP's, JDS, and CDP.

I'm hopeful that this actually means that we don't have to do anything different; that indeed the Access Key ID and password and type of CDP are irrelevant to file uploading, as the uploads don't actually go to the CDP. The CDP and JSS actually coordinate the subsequent syncing.

Of course this may just be wishful thinking.

Now that everything is working for JDS', I would first try setting up AutoPkgr with the newest JSSImporter version and configure a single JDS distribution point. The only key needed for a JDS is the "type" key, set to the value "JDS". The other fields are not used. I realize this seems counter-intuitive, but there's nothing that really specifies a JDS in the way the packages get uploaded, so this may work.

Then give it a try and see what happens.

Barring that, we would need to investigate what is actually happening. The way we did it, which you could try:

  • Start a packet capture with tcpdump and have it stream the results to a file.
  • Open Casper Admin app and add a package (and "save" it too, I think).
  • Stop your packet capture.
  • Then use Wireshark or your favorite packet sniffing tools to isolate the traffic between your computer and the JSS and figure out what is going on.

There's actually two ways packages can be uploaded that we discovered: One is the method used by Casper Admin, and the other is the one used when you use the web interface upload. python-jss currently uses the method used by Casper Admin, so that would be more useful information to have. You would specifically be looking for a POST or PUT (possibly to the path /dbfileupload at your JSS), but that's of course if it really works the same way as JDS'.

I would need to know the URL that this POST or PUT goes to, as well as the headers that get sent with it.

Unfortunately we don't have a CDP to do this on, so you're going to have to be our remote collaborator!

@luisgiraldo
Copy link

@sheagcraig This week is a write-off for me I'm afraid, but let me reach out next week and we'll play around a bit (if you'll be around/available?).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants