On 1/21/11 11:22 AM, "Michiel Beijen"
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