Glad to hear that there is work being done to get a .deb out there. Just in case you weren't aware, the backports repo is a great way to upgrade software whose dependencies haven't changed too much. This would easily allow for a 3.0.5 -> 3.1 upgrade with minimal trouble. Thanks for the info. Munroe Sollog Systems Engineer Digirati Consulting, Inc sollog@digiraticonsulting.com On 01/20/2011 02:31 AM, Michiel Beijen wrote:

Hi Munroe,

Actually, I guess the Debian package maintainer is working on something like that. But while I think a Debian package can be a nice way to quickly evaluate OTRS, I don't really think the Debian package is a good alternative from an OTRS installation 'from source'.

The problem is that the only way to ever upgrade your OTRS system if you use the package from the Debian repositories is to upgrade your OS, which is something you rather would not do. If you install OTRS from the .tar.gz file you have all the flexibility you need. You can upgrade to OTRS 3.1 when it comes available and if you want to, or you can choose to stay on the same version when upgrading your OS.

At some point we might start making .deb packages for Ubuntu and Debian available from http://otrs.org/downloads just as we do for RHEL and SLES - when you install them from our website, and outside of the system repositories, you won't have these issues.

Kindest regards,

Mike

On Wed, Jan 19, 2011 at 11:00 PM, Munroe Sollog wrote:

...

Does anyone know if there will be a debian package available for OTRS3?

-- Munroe Sollog Systems Engineer Digirati Consulting, Inc sollog@digiraticonsulting.com

--------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

--------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

On 1/20/11 5:50 PM, "Nils Leideck" wrote:

, the OTRS DEBIAN package is totally DEBIAN-ished and not just a ³let it try out² version! Of course, there are DEBIAN specific issues/differences compared to the standard OTRS, but that is not too bad as it just helps to keep the DEBIAN way of file organization.

One wish: please fix the Debian package so that if we do the change documented to allow the OTRS package manager to function correctly, that the packages actually work. Previous versions of the "Debian-ized" OTRS package caused enormous problems with the OTRS package manager, which makes using the ITSM features an enormous PITA. Also, a comment: installing from source outside the packaging system (ANY packaging system, rpm/deb/SMP/E/whatever) pretty much renders a tool not viable in a enterprise setting. You lose the ability to do release management in any useful way at scale. Not a good idea to recommend such -- we need to fix the problem. Does anyone know if OTRS is built using a build system like cmake? It might be interesting to look into that; that would provide the ability to automatically build RPM, DEB, Solaris pkgadd, and AIX installp packages as part of the build system.

On 1/21/11 11:22 AM, "Michiel Beijen" wrote:

We can't do a thing about that, it's one of the reasons I don't like the Debian package much. It's because of Debian package management restrictions. They say a web application can't be allowed to modify configuration data, and that's just what OTRS does in the SysConfig and Package Manager. See their bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=383776 for it. It's solved by including a README with instructions on how to adjust the permissions. It does not also affect OTRS, also their Wordpress package for instance is horribly broken, in much the same way and for the same reasons.

Yes, I understood that part of the problem, and have done the icky hack to "solve" the problem. The problem I'm after is that even when I have done the hack, using the OTRS package manager (the one inside the app) still has problems. Some of the OTRS packages appear to assume certain paths for installation (eg otrs vs otrs2 in the case of the otrs2 Debian dpkg) and don't seem to actually consult where the package is actually installed. We need to either fix where the Debian package puts files, or fix the OTRS internal packages to deal with having the files in a non-standard location. One way to solve the distribution option problem would be to split the package into two packages -- one that installs all the files and does all the current processing that is distributed through the normal distribution repositories, and a second package that only performs the steps to enable the WWW configuration and OTRS package manager, potentially adding any symlinks needed to make the internal OTRS package manager see the correct set of directories. The second package can be distributed from a private OTRS-sponsored repository, where any main tree restrictions just don't apply. Same approach would work for yum (any of the RH derivatives) and zypper (on SuSE), substituting the appropriate terminology and repository technology.

...

Also, a comment: installing from source outside the packaging system (ANY packaging system, rpm/deb/SMP/E/whatever) pretty much renders a tool not viable in a enterprise setting. You lose the ability to do release management in any useful way at scale. Not a good idea to recommend such -- we need to fix the problem.

So you mean you'd have issues if we supply an RPM or DEB that installs itself nicely in /opt? I guess many sysadmins will be happy with that.

No, I am arguing that we should never advocate doing source tarball installs on distributions that support a package management system as a matter of policy. Doing that makes software management and upgrades much harder on the sysadmin, which is most visible in enterprise sites where you may have to deal with many machines. Anything that makes one do something "different" for one machines is automatically Bad. I'm perfectly happy with an install package that uses /opt nicely. I'm objecting that we shouldn't lead our less-experienced colleagues astray off the Righteous Path of Good Practice and down the path to Evil Ways. The next person that might have to maintain such a system could be you...8-)

I assume you're a seasoned sysadmin, what would your goal be?

See above. I'm OK with having all the distributions supplying a "safe" version with everything potentially hazardous turned off, and adding a new software repository to /etc/apt/apt.sources (or equivalent, that's already a managed file in my environment, and everybody has the same one) allow OTRS to supply packages (in my native packaging system format) that turn on specific functions that distributions may not want to do, or may find too risky to turn on by default. Example: Let's assume I have a Debian system, and that OTRS maintains a repository at debian.repository.otrs.com to distribute the "enabler" dpkg. If I want just the "safe" version, I just "apt-get install otrs3" from the Debian repositories and go on my merry way. If I want the "standard" OTRS functionality as distributed by tarball, I could: 1) apt-get install otrs3 2) edit /etc/apt/apt.sources to add debian.repository.otrs.com 3) apt-get install otrs3-enable-www-configuration Package otrs3-enable-www-configuration contains no files but a postinstall script that does the "hack" solution, and has a hard prereq of the main otrs3 package. Since I want a completely working OTRS3 as documented, I do steps 2 and 3, and I get the fully operational package. I have consciously assumed any risk by adding the additional repository. Wrt the actual OTRS packages installed with the OTRS package manager, someone needs to check that they actually obey the location environment variables established by the software configuration instead of assuming the "standard" paths.

I know some people are working on updating the Fedora package for OTRS; in my opinion it would be nice if we could get OTRS in EPEL (Extra Packages for Enterprise Linux). Or do you think it would be best if we'd set up an extra repository for RHEL/Centos and Debian/Ubuntu systems, that sysadmins can add to their repo list. What would you prefer?

In general, I would ultimately prefer EPEL (we already include EPEL in our standard search list for repositories for a lot of other reasons), but the solution I describe above would work more quickly and doesn't require getting so many stars to align. Setting up a yum and debian repository at otrs.com to do the "enable" trick shouldn't take more than an hour or so each, and would really help the process, I think.

...

Does anyone know if OTRS is built using a build system like cmake? It might be interesting to look into that; that would provide the ability to automatically build RPM, DEB, Solaris pkgadd, and AIX installp packages as part of the build system.

Actually, since OTRS is a Perl application, it is not actually 'built'. It's not compiled or so. It just has dependencies to Perl modules, of which some (for instance a database driver like DBD::mysql) do require compilation. Currently we automatically build the RPMs on our infrastructure every time we do a release.

Even with non-compiled languages, it might still be helpful to have a build framework, especially if there is a mixture of compiled and non-compiled code. I'm familiar with cmake from other projects (mostly KDE), and it's really handy with large projects of all types (C, C++, Ada, Perl, python, rexx, etc, etc). Cmake, ctest, and cpack are really, really elegant ways to structure deployment that has to work on multiple platforms -- they handle the details of what files go where, configuration, details of what options are needed to different utilities, etc, etc. Other similar tools exist; I just thought of cmake immediately.

BTW I don't know about anyone actually using AIX to run OTRS, would be interesting to know... Some time ago I did assist some people deploying OTRS on DB2, but even that's absolutely not very common.

Guess I'm the only one. It works, once you sort out the differences in where things go vs where they should go, and all kinds of other stuff. I mentioned it above because cpack knows how to generate the magic AIX package format from the same common source tree without changing the code. Cpack also knows how to do Windows NSIS packages and a couple more platforms, too. It's just a thought how OTRS could be supported in a lot more environments with minimal extra work. -- db