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?
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.
The SLES12 option need the zombie emoticon in the docs
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.
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.
