[Spacewalk-list] [CLOSED+SOLUTION] Sles Patchlvl 4 Spacewalk-Service fail

Thu Jul 30 04:11:05 UTC 2015

Suse manger exists to purely get more $$ out of businesses , they charge
$10k for it even though its just a rebranded spacewalk, personally I
have no issues paying for a patching product that works, but taking
another GPL project rebranding and changing certain sections then
calling it your own and charging such a high price is just insane, those
are my personal thoughts anyway. 

On 2015-07-30 15:03, prmarino1 at gmail.com wrote: 

> Fair warning this is a little harsh but true. 
> There are a couple of things in this thread which I agree with and some I dont. 
> For the spacewalk development team: 
> On the client and server side there is a way to query the API version. It would be better if the client specified the API version in each message and the server had backward compatibility for at least 1 version. 
> The reverse backward compatibility would also be nice‎ and if both were done it would resolve a lot (if not all) of the upgrade issues with spacewalk. 
> 
> For the original person who started this chain: 
> Question: Why does SuSE manager exist? 
> Disclaimer: I do not now nor have I ever worked for Red Hat or SuSE. ‎My answer is based on 19+ years making al living on supporting and writing free speech software, in vry industry from municipal school systems, several stock exchanges, broadcast media, and web. 
> Comment: Stop being a troll. 
> Answer: Industry requirements, government regulations and infosec standards, that's why!!! 
> Some history Spacewalk predates SUSE Manager! 
> Actual reasons why SuSE manage exists‎. 
> Reasons: 
> 1) There are a lot of industry standards, government regulations, and even international treaties which require for many industries that require you have a support contract unless you can prove you have a sufficient in number and quality development and quality assurance team to prove you are making a "best effort" to ensure all relivant security patches are being installed in a "timely manner". what that means is if your buissness requiers you to comply with one of these standards or regulations, unless your company is running hundreds of thousands of servers economically it doesn't make much sense to not pay for support; because the team required to meet the expectation of those standards is way too cost prohibitive. 
> 2) Why shouldn't developers of GPL software be payed for their efforts. Even RMS has pointed this out repeatedly, and if you don't think that's true read the GNU manifesto some time. The GNU manifesto points out several business models on how to make money by producing free speach software. In this case of Spacewalk currently both SUSE and Red Hat are persisly following one of the models layed out in the GNU manifesto. 
> 
> FROM: VeNoMouS 
> SENT: Wednesday, July 29, 2015 20:27 
> TO: Bosch, Fabian (BITBW) 
> REPLY TO: spacewalk-list at redhat.com 
> CC: spacewalk-list at redhat.com 
> SUBJECT: Re: [Spacewalk-list] [CLOSED+SOLUTION] Sles Patchlvl 4 Spacewalk-Service fail 
> 
> Moving forward it would be nice if spacewalk team put backwards compatibility for the function call they changed in rhnlib... 
> 
> On 2015-07-29 20:33, Bosch, Fabian (BITBW) wrote: 
> 
> EXACTLY! THANKS.
> 
> This did the trick: (remember: I am on a SLES SP4 Client-System) 
> 
> Rename functions in /usr/lib64/python2.6/site-packages/rhn/connections.py 
> 
> line 241 
> 
> def idn_pune_to_unicode(hostname): 
> 
> to 
> 
> def idn_puny_to_unicode(hostname): 
> 
> line 248 
> 
> def idn_ascii_to_pune(hostname): 
> 
> to 
> 
> def idn_ascii_to_puny(hostname): 
> 
> And make sure, that the Up2date config under /usr/share/rhn/up2date_client/config.py
> imports and uses the new name. 
> 
> Make a search & replace 
> 
> idn_pune_to_unicode 
> 
> to 
> 
> idn_puny_to_unicode 
> 
> idn_ascii_to_pune 
> 
> to 
> 
> idn_ascii_to_puny 
> 
> so that the up2date references the right function.
> 
> last step:
> renew/review your information in the /etc/sysconfig/rhn/up2date 
> 
> worked for me. 
> 
> Thanks to all
> 
> Freundliche Grüße 
> 
> Fabian Bosch 
> 
> Referat 34 - Open Source 
> 
> Tel: 94476, Raum: KRA 1.68 
> 
> VON: VeNoMouS [mailto:venom at gen-x.co.nz] 
> GESENDET: Mittwoch, 29. Juli 2015 10:00
> AN: spacewalk-list at redhat.com
> CC: Bosch, Fabian (BITBW)
> BETREFF: Re: [Spacewalk-list] Sles Patchlvl 4 Spacewalk-Service fail 
> 
> Could be same thing related to what I posted here https://bugzilla.redhat.com/show_bug.cgi?id=1235574 [1] I run SLES 11.3 
> 
> On 2015-07-29 19:18, Bosch, Fabian (BITBW) wrote: 
> 
> Hi @ all 
> 
> I recently upgraded SLES to newly released Patchlevel 4. The System has been registered an working unter Patchlevel 3 with Spacewalk v2.3.
> The Upgrade via Spacewalk/zypper worked fine, but after Dist-Upgrade spacewalk-service stopped working and is now skipped. 
> The only message I got was that I have to install spacewalk-backend-libs. No Information about the required Version - spacewalk-backend-libs needs _python(abi)=2.7._ 
> 
> Never heared neither have such a package.
> 
> Anyone has experience with SLES SP4 and Spacewalk? Are there additional packages needed providing python(abi) or are there client-tools for Patchlevel 4 in the tube? 
> 
> Software installed:
> rhn-client-tools 2.3.16-3.1 
> 
> Rhnsd 5.0.15-3.1 
> 
> Rhnlib-2.5.75-2.1 
> 
> Zypp-plugin-spacewalk-0.9.9-3.1 
> 
> Just for your Information: 
> 
> Why SLES ?? - It wasn't my Choice ☺ And now I want to demonstrate that there is no need for SUSE Manager - a proprietary Patchmanagement based on Spacewalk.
> 
> Regards, 
> 
> Fabian Bosch 
> 
> Referat 34 - Open Source 
> 
> IT Baden-Württemberg (BITBW) 
> 
> Krailenshaldenstraße 44 
> 
> 70469 Stuttgart 
> 
> Telefon: +49 711 8910-94476
> Telefax: +49 711 8910-17575 
> 
> E-Mail: fabian.bosch at bitbw.bwl.de 
> 
> Internet: www.bitbw.de [2] 
> 
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list [3]

_______________________________________________
 Spacewalk-list mailing list
 Spacewalk-list at redhat.com
 https://www.redhat.com/mailman/listinfo/spacewalk-list [3] 

Links:
------
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1235574
[2] http://www.bitbw.de
[3] https://www.redhat.com/mailman/listinfo/spacewalk-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20150730/43a93073/attachment.htm>