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, [email protected] 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: [email protected] 
> CC: [email protected] 
> 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:[email protected]] 
> GESENDET: Mittwoch, 29. Juli 2015 10:00
> AN: [email protected]
> 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: [email protected] 
> 
> Internet: www.bitbw.de [2] 
> 
> _______________________________________________
> Spacewalk-list mailing list
> [email protected]
> https://www.redhat.com/mailman/listinfo/spacewalk-list [3]

_______________________________________________
 Spacewalk-list mailing list
 [email protected]
 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
_______________________________________________
Spacewalk-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/spacewalk-list

Reply via email to