Re: [otrs] RPM repo (was: FW: OTRS 3.2 beta – statement from Manuel Hecht, Vice President Global Software Development)
Hi David,
Thanks for the suggestion - I appreciate your concern. Better packaging has
been long on our wish list but the list is long and the amount of hours in
a day is not.
Anyway, to be able to pull this off the upgrade process for patch level
updates should be fool proof and should not require manual actions.
Currently, it would still require manual reinstallation of packages via the
OTRS package manager in case you are using ITSM, for instance. This should
be taken care of by the RPM. That is totally fixable.
And we should create different repositories for the different minor
revisions, so if you would like to upgrade from OTRS 3.1 to 3.2 you could
do that by changing your package repository and running yum upgrade plus
any post install actions, and if you would not change the repo you will
keep on receiving 3.1.x updates.
One other topic is that we currently do not ship with an SELinux profile,
which forces people to set selinux to permissive.
Would there be any RHEL syadmin that can help with the SElinux profile?
Would there be people interested in testing such an RPM repo?
--
Mike.
Op 27 nov. 2012 16:35 schreef "David Boyes"
Thanks for the suggestion - I appreciate your concern. Better packaging has been long on our wish list but the list is long and the amount of hours in a day is not. Yeah. These days it’s a real distinguishing factor, especially for enterprise-grade stuff. IBM and Oracle get this one wrong most of the time, and we yell at them too. 8-) Enterprises don’t have time or extra bodies to deal with software that doesn’t work easily with the native software management strategy and tooling. You’re getting into the big time, and special cases that don’t use the native packaging systems (and have sub-packages that aren’t represented in the native packaging system) are a real PITA for configuration-managed environments. Special cases = bad for enterprise management. But, anyway. It’d do a lot to make testing easier if we could just set up a virtual machine, tell it where the latest version is, and just “yum install” to pull in all the other stuff OTRS needs. With that, I can easily create test instances and use the time to test the software instead of building the environment to test it. 8-) Anyway, to be able to pull this off the upgrade process for patch level updates should be fool proof and should not require manual actions. Desirable, but not in the critical path. I’d really settle for just having a repo to get the known current stable and beta builds (one for each). That’d be good enough for now. (In fact, I’d look at something like what OpenERP does – provide a daily build of the stable release in a known location and leave it at that. I don’t mind doing the additional steps while you evolve packaging strategies). Currently, it would still require manual reinstallation of packages via the OTRS package manager in case you are using ITSM, for instance. This should be taken care of by the RPM. That is totally fixable. A dummy RPM for each OTRS internal package that did the OTRS pkg mgr install commands in the postinstall script probably would be sufficient. Something similar to the RPM packaging of the CPAN libraries would be super, and could be programmatically generated. And we should create different repositories for the different minor revisions, so if you would like to upgrade from OTRS 3.1 to 3.2 you could do that by changing your package repository and running yum upgrade plus any post install actions, and if you would not change the repo you will keep on receiving 3.1.x updates. Holy Grail. 8-) See above. That can come later. Focus on the initial sw distribution problem for new builds first. Much smaller task. Ø One other topic is that we currently do not ship with an SELinux profile, which forces people to set selinux to permissive.Would there be any RHEL syadmin that can help with the SElinux profile? If you can give me a log file from running a production OTRS in permissive mode/with “setenforce 0” on for a couple weeks, I can get someone to look at it and come up with a proposed policy file. We’re in the middle of doing a bunch of other profiles, one more won’t be a huge hassle. 8-) Would there be people interested in testing such an RPM repo? YES. I’ve got virtual machines just sitting here waiting to try it. (Something else that just occurred to me: if you do this, it’d be trivial to use VMWare Studio to build a complete ready-to-use OTRS appliance image. THAT would be cool – base it on Centos or OpenSUSE, and distribute a complete known working system, either for testing or real use. Would save a huge amount of startup questions – if you do the repo, I’ll try generating one. )
To go further, the files needed to do the repository definition RPM are attached to this message. Put the OTRS RPM in a dir on your WWW server.. Fix your WWW server configuration to make that directory available via the WWW server
Then, edit the .repo files attached to reflect the URL of that dir (the baseurl= line is the critical one, although the one in the spec file should match) and run rpmbuild on the spec file. Put the resulting RPM somewhere on the WWW site (the same dir as the OTRS RPM is fine) and run ‘createrepo’ in that directory.
You can then have people do ‘rpm –Uvh http://whereveryouputit.otrs.com/otrs-stable-repo.xxxxx.noarch.rpm’. That will install the repository and integrate it into yum.
Then ‘yum listrepo’ to check that it installed correctly. Then ‘yum install otrs-rpm-name’ and watch the fun.
From: otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] On Behalf Of Michiel Beijen
Sent: Tuesday, November 27, 2012 1:55 PM
To: User questions and discussions about OTRS.
Subject: Re: [otrs] RPM repo (was: FW: OTRS 3.2 beta – statement from Manuel Hecht, Vice President Global Software Development)
Hi David,
Thanks for the suggestion - I appreciate your concern. Better packaging has been long on our wish list but the list is long and the amount of hours in a day is not.
Anyway, to be able to pull this off the upgrade process for patch level updates should be fool proof and should not require manual actions. Currently, it would still require manual reinstallation of packages via the OTRS package manager in case you are using ITSM, for instance. This should be taken care of by the RPM. That is totally fixable.
And we should create different repositories for the different minor revisions, so if you would like to upgrade from OTRS 3.1 to 3.2 you could do that by changing your package repository and running yum upgrade plus any post install actions, and if you would not change the repo you will keep on receiving 3.1.x updates.
One other topic is that we currently do not ship with an SELinux profile, which forces people to set selinux to permissive.
Would there be any RHEL syadmin that can help with the SElinux profile?
Would there be people interested in testing such an RPM repo?
--
Mike.
Op 27 nov. 2012 16:35 schreef "David Boyes"
participants (2)
-
David Boyes -
Michiel Beijen