-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Dear VeNoMous. Hopefully this wont we a flamewar. Am 30.07.15 um 06:11 schrieb VeNoMouS: > > > 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. > - From my point of view.... 10k is more than cheap for a professional Solution. Maybe you should recheck what Redhat is charging you for Sat. Or Oracle/SUN for XVM Ops Center. Out there are many Companies who need professional Support and a solid Platform. That is why the pay Support. Everybody has to make a living. Its absolutely not insane charging Enterprise Customers for Support. Think about it. Just my 2 cents and take Care. > 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 > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVulhbAAoJEHxIkeoL34IfcaIH/0k9ZXGUjOVrzt7IwaZ9EYwh O6GKMGncrO5Mmdha+718Ymgqf+bZAAJVX58//th/mJDnxGJvQnaWe1GPPL2dufPJ CO4c6VMUgtw9D4LpdE81GjV8sSMsrJgmrmnr5ueNog5ylY10vGoNY7gozdqXkYPa j+bZMP9XN0n7CudymK3aZznhADCURQoT98uy6RN958WVtaWG93F+x7evzDHJJXiK L7uLU1viaTSKf6O6mE5nvvItlKcAnnCoXsV3e2At2XG3Un/UXzBPcC5T14giH17L 4DvzSow6d47kEE/eiyJOzLhyKHGPZ76Y2UjJGAVHpfNL25BOCVCjXpYhxpPp114= =3rlb -----END PGP SIGNATURE----- _______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list
