<!DOCTYPE html><html><head>
<style type="text/css">body { font-family:'DejaVu Sans Mono'; font-size:12px}</style>
</head>
<body><div>Hi Jake,</div><div><br></div><div>On Mon, 01 Jul 2013 12:37:11 -0400, Jake Davis <jake@imapenguin.com> wrote:<br></div><blockquote style="margin: 0 0 0.80ex; border-left: #0000FF 2px solid; padding-left: 1ex"><div dir="ltr"><div><div>Thanks for the clarification. I can work with that. <br>It brings up a couple of question in regards to automation. In essence I will want to do something like copy all units from upstream that are not already in testing (minus "kernel-*"). Do I need to manually determine the delta between upstream and testing to craft my filter, or is there some way to automatically avoid copying duplicate units? Or is the nature of the storage such that copying is too cheap to concern ourselves with duplicate operations? Examples would be quite valuable :)</div></div></div></blockquote><div><br></div><div>There is probably not a great way to automatically avoid calling copy on duplicate units, but copying in Pulp is a very cheap operation, especially when the unit is already associated with the destination repository. It should be fast enough that it's not worth trying to avoid copying duplicates, because it is very likely a no-op. I should mention that things will get more expensive if dependency resolution is involved.<br>
<br></div><blockquote style="margin: 0 0 0.80ex; border-left: #0000FF 2px solid; padding-left: 1ex"><div dir="ltr"><div>Also, I can schedule a sync but not a copy operation. Would I need to pass --password on the command line to automate, or is there another way that doesn't involve human intervention?</div></div></blockquote><div><br></div><div>pulp-admin login will retrieve a certificate that can be used for a while to authenticate against the API, so that subsequent calls to pulp-admin don't need the --password flag. There are a few caveats to using this approach:<br></div><div><br></div><div>1) The certificate does expire, I think every two weeks. I am not sure if this is currently configurable.</div><div><br></div><div>2) You would need to call login with the same user that will be performing the automated calls.</div><div><br></div><div>3) Due to a bug[0], the authentication certificates are stored world-readable by default, so you might wish to chmod them to 600.</div><div><br></div><div>All of this is weighed against the security risk of using the --password on the command line, since process arguments are available for users on the system to read.</div><div><br></div><div>[0] https://bugzilla.redhat.com/show_bug.cgi?id=980506</div><br><div id="M2Signature"><div>-- </div><div>Randy Barlow</div></div></body></html>