Content
Added by Matthew Trescott over 2 years ago
TL;DR: You can now install OpenProject easily on openSUSE. The packages are built on the Open Build Service. You can read about how to install and use them on the openSUSE Wiki (only English for now—but if I can clarify anything, please let me know).
I wanted to package OpenProject in a more "traditional" way and provide more flexibility for distributed setups (such as hosting repositories, PostgreSQL, or Memcached on separate servers). I also wanted to provide more in-depth technical documentation that would be useful to someone who is familiar with Linux and Apache, but not familiar with Ruby on Rails or OpenProject. There are a few differences compared to the official packages (these are the most significant ones):
- Cons:
- Bundler is not used; instead, the
gemfunction is directly to control which version of a Ruby library will be used. The benefit of this is that bug fixes in Ruby Gems will be take effect as soon as you install them and restart OpenProject. The risk is that a Gem upgrade in the future will break something. I'm not sure whether this is - You cannot serve OpenProject in a subdirectory (e.g. example.com/openproject); you have to serve it at the web server root. This is because all the core OpenProject files (Ruby code and assets) are compiled when the package is built and are installed read-only for all users except root and are overwritten on package upgrades.
- Bundler is not used; instead, the
- Pros:
- The Puma web server is used instead of Unicorn, and it serves OpenProject (by default) on a Unix domain socket instead of via TCP/IP loopback. Unix domain sockets avoid some overhead in the Linux kernel and should be marginally faster. Puma (unlike Unicorn and Passenger Community Edition) supports threading, which allows requests to be processed by one thread while another thread is waiting for a response from the database. This should provide a meaningful speed improvement.
- Puma is configured by default to use systemd socket activation.
- The Rails
:file_storecaching backend uses a private directory in/run/openprojectwhich is typically mounted with tmpfs. This improves performance out-of-the-box even without using Memcached. - The Apache configuration files are thoroughly documented with comments and you are encouraged to edit them to suit your needs (although they will work almost out-of-the-box).
- Repositories can be easily hosted on a separate (virtual) machine without installing the full OpenProject package.
- Because I was building these packages from scratch, I was also able to make the startup script much more concise than the scripts provided by Heroku Pkgr.
- Low-level configuration is done with the YaST Sysconfig Editor, which provides a nice GUI (and TUI) for low-level configuration, somwhat like the Windows Registry but with more documentation for the user.
- The Sys API (for repository authentication) is configured via environment variables in the YaST Sysconfig Editor instead of in the web app. This resolves some issues other users have encountered with the Sys API checkbox not working in the web app.
Feedback is very much welcome! My goal is to eventually submit the package for inclusion in the core openSUSE distribution, which hopefully would get OpenProject some more publicity. (It is an amazing piece of software!)
Replies (6)
Hi Matthew,
great work and thanks for your feedback. I added a reference to our documentation that points to your wiki page, so you can keep control over the documentation. Let us know if you need any tech support with this packaging process going forward. If you plan to keep this supported, we can also move your wiki page into our docs page and you can edit it through pull requests.
Best
Oliver
Hello, and thanks for your contribution, it really is a lot of work.
We are planning on defaulting to Puma for the packages as well, for the reasons you mentioned. It hasn't been enabled yet, for backwards compatibility reasons, but it's something that should come soon.
Starting fresh and targeting a single distribution means you can indeed use more concise configuration files and use specific features of the OS like the YaST editor. However the more distributions you support, the more you need to handle various edge cases in all the different versions of (say) Apache, which quickly makes your packaging files more complex than you'd like.
Regarding the gem dependencies, it seems you also build them specifically for the OpenProject package? I had a look at the OBS page but couldn't find the underlying files that specify how everything is built. Could you add a pointer for me?
Thanks!
Cyril
Oliver—
Thanks for your interest and adding the link to your documentation! My plan is to eventually get all the packages merged into upstream openSUSE and maintain it there. (So eventually the wiki page would be moved into the main openSUSE wiki instead of being a sub-page under my username.)
Cyril—
It sure was, especially since I had never written a single line of Ruby or worked with an RPM specfile much before this project! But I think I've got most of the kinks ironed out now. (Probably the most confusing issue I encountered was where puma-plugin-systemd created a Status class in the global namespace, which interfered with OpenProject's Status class.)
You are right, being able to be more concise is definitely a result of being able to focus on one distribution. These packages would require a lot of work to be used on a different distro, mostly because no other distribution (as far as I can tell) packages as many Ruby Gems into RPM packages as openSUSE. (openSUSE uses Ruby a lot—YaST is written in Ruby, along with various openSUSE web apps, including OBS.)
Where possible, I used Ruby Gems that were already packaged as RPMs in the openSUSE repositories. The Gems in my OBS project are only the dependencies that weren't already packaged or needed special patches (you can see the RPM specfile by clicking on the package name—for example, rubygem-date_validator). This is mostly automated by the wonderful gem2rpm script and macros maintained by the Fedora and openSUSE developers. gem2rpm reads a configuration file (gem2rpm.yml) and generates an RPM specfile by extracting metadata from the Gem package, then it installs it in the fakeroot environment with all available Ruby interpreter versions, so that subpackages get generated for each Ruby version (e.g.
ruby2.6-rubygem-date_validatorandruby2.7-rubygem-date_validator). There's a good introduction to gem2rpm also on the openSUSE wiki.To work with the files on OBS locally, you use the
oscclient, which uses Subversion under the hood. I just started out by reading the article on the openSUSE wiki called "How to contribute to Factory." The openSUSE Packaging Portal is also a very good reference.Hope that helps explain things! Best regards,
Matthew
I've updated the packages to use Puma 5 and have re-based my patches to work with the release/11.0 branch. The 11.0 development version package sources are in the openproject-dev package on the Open Build Service repository, but the build is disabled so it won't cause conflicts in the repository. However I built the package locally and uploaded it to my test server and it is working :)
So when OpenProject 11.0 is ready hopefully my packages will be too!
(By the way, I keep my patches in my fork on GitHub in the branches "MTres19/opensuse-packaging-2" (for v10.6.5) and "MTres19/opensuse-packaging-op11" (for v11.0))
Packages have been updated for OpenProject 11.0 and are available (as before) on the Open Build Service!
Thanks a lot, Matthew!