Installation on OpenSUSE Leap 15.3 fails due to missing addgroup command

Infos:

  • Used Zammad version: Latest
  • Used Zammad installation type: package
  • Operating system: OpenSUSE Leap 15.3

Expected behavior:

  • Zammad is installed from package

Actual behavior:

/var/tmp/rpm-tmp.8jbi7A: line 18: addgroup: command not found
error: %prein(zammad-5.2.1-1657222873.979ea9ca.sles12.x86_64) scriptlet failed, exit status 127
error: zammad-5.2.1-1657222873.979ea9ca.sles12.x86_64: install failed
(17/17) Installing: zammad-5.2.1-1657222873.979ea9ca.sles12.x86_64............................................................................................................[error]
Installation of zammad-5.2.1-1657222873.979ea9ca.sles12.x86_64 failed:
Error: Subprocess failed. Error: RPM failed: Command exited with status 1.

Steps to reproduce the behavior:

  • Follow the documentation for installation in OpenSUSE
  • zypper install zammad

There does not seem to be a package for OpenSUSE that provides addgroup, or my google-fu is failing me.

Is there an additional package I am missing?

If OpenSUSE 15.3 not supported, what is the best option for installation?

Installing from source is a PITA with updates, and docker is not officially supported (and I only have cursory knowledge of docker).

https://docs.zammad.org/en/latest/prerequisites/software.html#supported-distributions

In other words: Use a different distribution?

How unsupported / troublesome is the Docker route truely for productive use, especially when it comes to updates?

Downgrading to an OpenSUSE version from 2017 is not a workable solution.

Why not run it on either Ubuntu 20.04 LTS or Debian 11? These are both stable and supported releases and receive regular security updates for the OS.

We are a very small staff (with quite limited Linux knowledge) so we needed to standardize our infrastructure and to limit the scope of our support contract.

I am frankly very surprised OpenSUSE does not have addgroup / adduser, I do remember the commands as pretty standard. And googling for a solution, I did not find a reason why it is not made available.

Fair enough, I am guessing the folks at SUSE decided to deprecate adduser and addgroup in favour of the useradd and groupadd commands. RPM-based operating systems such as Fedora or CentOS seem to have followed in deprecating addgroup as well.

It made sense to deprecate the adduser and addgroup commands though, look at the list of related commands for manipulating users or groups:

useradd - create a new user or update default new user information
usermod - modify a user account
userdel - delete a user account and related files
groupadd - create a new group
groupmod - modify a group definition on the system
groupdel - delete a group

Can you see why adduser and addgroup are the odd ones out?

Here is the curious thing:

The six commands you listed are the commands doing the actual work of user & group manipulation.

adduser / addgroup is a convenience wrapper for them, mostly intended for interactive use, offering a friendlier interface and some convenience like creating the home directory. That memory came back to me from an earlier life, when I was involved in the Debian project and confirmed by google search.

I don’t believe the post-install script of the package should use addgroup in the first place. groupadd would be portable and safe across distributions.

I checked the OpenSUSE packaging guidelines, and they prescribe a different approach still. But I don’t know if the Zammad build process and if that is feasible.

I found the adduser / addgroup implementation used in Ubuntu, which is a perl wrapper for the user* and group* command. I will put that one in /usr/local/sbin and cross my fingers that this will be sufficient to finish the package installation.

OK, so installing the adduser script and Debian::AdduserCommon and creating the appropriate symlinks got me over that blocker.

Things are still not good, unfortunately.

LoadError: libssl.so.1.0.0: cannot open shared object file: No such file or directory - /opt/zammad/vendor/bundle/ruby/3.0.0/gems/openssl-3.0.0/lib/openssl.so

I had to install the libopenssl1_0_0 package to get rid of that error. The already installed libopenssl1_1 package fulfilled zammad’s package requirements, so there must be an error in those.

# zammad run rails r "Setting.set('es_url', 'http://localhost:9200')"
/opt/zammad/vendor/bundle/ruby/3.0.0/gems/bootsnap-1.12.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:30:in `require': libffi.so.4: cannot open shared object file: No such file or directory - /opt/zammad/vendor/bundle/ruby/3.0.0/gems/ffi-1.15.5/lib/ffi_c.so (LoadError)

And this is the point at which I am putting a stop to it. I have libffi7 installed. I could hunt down some ancient a libffi4 package. But stability and maintenance wise, this is going in the wrong direction.

I can only imagine, Zammad has a well paying customer that is stuck at that geriatric SLES version and this is the reason why the Zammad package gets updated, but is stuck OS wise.

This means for me, that I have to look into the Docker version. Not great, but still the most workable solution for us. And we’ll see what that means wrt to purchasing the support contract Zammad offers.

Yeah well the documentation is not lying to you when it tells you that SLES12 packages are not compatible to SLES15 / Leap 15.x right? :slight_smile:

I personally would ditch SuSe as I personally had way too many issues with it but that’s your decision in the end.

1 Like

The SLES12 option need the zombie emoticon in the docs :man_zombie: :man_zombie: :slightly_smiling_face:

Unfortunately, migrating systems or maintaining different distributions is currently not an option, we are too understaffed to do anything in that direction right now.

If you run Zammad on docker, it is fine. But we just support the application!

Does this mean that if we were to purchase a support option, if would cover anything going on inside the container, but the OS and running / configuring docker is on us?

That is correct.
Even if you have a support contract you’ll need knowledge of your dependencies - in that case especially docker. No support contract covers OS maintenance and support on 3rd party applications like Elasticsearch is limited.

Alright, thanks for the info!

A small addition possibly if you don’t want to have to worry about maintaining Zammad at all would be to use Zammads SaaS offer. However, that of course only applies if the support contract is not the better financial approach as hosting for big instances can be pricy.

The SaaS option would not work for us, we need the AD/LDAP integration for one and we cannot allow external access.

I got the docker-compose version to install, but run into trouble due to lack of knowledge about docker. Like the search index rebuild command giving an error about not being able to connect.

So we bit the bullet and installed zammad on centOS. That went well, now I am cleaning up our OTRS before I try the migration.