[Spacewalk-list] [patch] spacecmd fails on Base64 encoded data and UTF-8

[Aron Parsons]

Thanks David, committed as 1f0896775c6e9651a99e91b062c0629e84e84f48.  If
possible, please use a git-formatted patch in the future so it has the
author and message already in the patch.

Not sure on the UTF-8 issue as I haven't seen that pop up.  I'll run
through my script output history on a busier Spacewalk instance and see if
I can recreate tomorrow.

/aron


> ________________________________________
> Date: Mon, 23 Sep 2013 11:35:21 +0200
> From: David Juran <djuran at redhat.com>
> To: spacewalk-list at redhat.com
> Subject: [Spacewalk-list] [patch] spacecmd fails on Base64 encoded
>         data and        UTF-8
> Message-ID: <1379928921.5526.13.camel at localhost.localdomain>
> Content-Type: text/plain; charset="utf-8"
>
> Hello!
>
> Attached is a small patch which fixes spacecmd handling when Red Hat
> Satellite (5.5) occasionally chooses to return Base64 encoded data.
> There probably are more places where the Satellite can opt to return
> Base64 encoded data, it would be good to grep through the API docs and
> add the necessary support to spacecmd.
>
> I also got an error output
> ERROR: 'ascii' codec can't encode character u'\xe5' in position 392:
> ordinal not in range(128)
> and then the list of results (from schedule_getoutput) got truncated.
> The problem got solved by encoding the output as UTF-8 (inspiration
> gathered from do_kickstart_getcontent in kickstart.py) though I'm not
> quite quite sure why this encoding is necessary since the xmlrpclib
> manual states that the encoding by default is UTF-8 already.
> And on the other hand, if this statement really is necessary, it would
> be good if it was possible to somewhere set the "default" encoding to
> UTF-8 so that each and every print statement doesn't have to be
> modified. But that is where my feeble python-skills end, so maybe
> someone else have any ideas (-:
>
> --
> David Juran
> Sr. Consultant
> Red Hat
> +46-725-345801
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: spacecmd-output.patch
> Type: text/x-patch
> Size: 866 bytes
> Desc: not available
> URL: <
> https://www.redhat.com/archives/spacewalk-list/attachments/20130923/97adffef/attachment.bin
> >
>
> ------------------------------
>
> Message: 4
> Date: Mon, 23 Sep 2013 17:07:46 +0200
> From: David Juran <djuran at redhat.com>
> To: spacewalk-list at redhat.com
> Subject: [Spacewalk-list] [patch] spacecmd credentials cache doesn't
>         work    for normal user
> Message-ID: <1379948866.11335.24.camel at localhost.localdomain>
> Content-Type: text/plain; charset="utf-8"
>
> Hello!
>
> Spacecmd uses the user.listUsers API call to validate the credentials
> cache. This is suboptimal since a normal user isn't allowed to run this
> call, forcing him to always enter his password.
> The attached one-liner instead changes the test to api.getApiNamespaces
> to test the cache, but I guess any unprivileged operation would do.
>
> --
> David Juran
> Sr. Consultant
> Red Hat
> +46-725-345801
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: spacecmd-validate-credentials-cache.patch
> Type: text/x-patch
> Size: 527 bytes
> Desc: not available
> URL: <
> https://www.redhat.com/archives/spacewalk-list/attachments/20130923/309e4b21/attachment.bin
> >
>
> ------------------------------
>
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
> End of Spacewalk-list Digest, Vol 64, Issue 26
> **********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20130923/5480c47f/attachment.htm>