Simplifying repositories and eliminating 'doesn't support architecture' message with Debian and derivatives on ARM64 #593

johnheenan · 2023-07-16T12:12:30Z

On a Debian install of Virtualmin gpl on aarch64 (ARM64) there is a single line in file /etc/apt/sources.list.d/virtualmin.list

deb [signed-by=/usr/share/keyrings/debian-virtualmin-7.gpg] https://software.virtualmin.com/vm/7/gpl/apt virtualmin main

This causes the command apt update to look for packages for the 'ARM64' architecture. However, there are none. However, it is not necessary to look for such packages because all the required packages are already in architecture 'all'

Hence the error with apt update can be eliminated by changing the line to only look for packages for architecture 'all' only:

deb [arch=all signed-by=/usr/share/keyrings/debian-virtualmin-7.gpg] https://software.virtualmin.com/vm/7/gpl/apt virtualmin main

That is, add in arch=all after opening bracket.

In the virtualmin repo the contents for architectures 'all', 'i386' and 'amd64' are all identical and there is no architecture specific content in them.

So, by adding in arch=all to the repo line, the Virtualmin repo can be simplified by eliminating the content for the 'i386' and 'amd64' architectures.

Although the code solution for this issue belongs in the https://github.com/virtualmin/virtualmin-install, it is not practical to raise this issue there and include a PR due to line 1023 of file https://github.com/virtualmin/virtualmin-install/blob/master/virtualmin-install.sh#L1023

    for repo in $repos; do

The same can be applied for the use of the Webmin repository.

There is more information at https://forum.virtualmin.com/t/i-got-virtualmin-working-on-arm64-ampere/121442

The text was updated successfully, but these errors were encountered:

eugenefvdm · 2023-07-16T13:21:10Z

Thanks @johnheenan tested on a ARM64 instance and it worked. There were no actual updates as of today but I'll run it in the future when a new Virtualmin version comes out and then let's see. So far looks great though, thanks so much for your effort and perseverance in making Virtualmin more ARM64 friendly.

jcameron · 2023-07-16T16:19:26Z

Could we potentially also fix this for existing installs by adding more architecture-specific directories to the repo?

swelljoe · 2023-07-16T17:48:57Z

Yes, if the repo said it supports arm64, this message wouldn't happen. But, as far as I know the lack of it doesn't stop installing all packages from our repo, it just accurately says the repo doesn't have any arm64 packages. Am I wrong about that? You can install any of the all packages from the repo with or without this additional config option, right?

We've been planning to add support for arm64 when we get a little time for testing, as it is just one package. That hasn't happened yet, and getting yelled at about it isn't really helping motivate.

But, once that package (procmail-wrapper) is in the repo for arm64, I'd remake the repos with the extra architecture.

swelljoe · 2023-07-16T18:22:13Z

But, it seems wrong for the repo to say it supports arm64 without actually providing packages for arm64. If I'm spending time on it, I'd rather spend it on actually supporting arm64.

eugenefvdm · 2023-07-17T08:11:27Z

Here is how I compiled and installed procmail-wrapper on ARM64. As mentioned in another post I'm very happy to donate an ARM64 VM to the Virtualmin staff for a year for testing.

procmail-wrapper is actually a very simple command line parameter interpreter for Postfix which allows Virtualmin to hand off spam checking to other programs.

Original source

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

int main(int argc, char **argv)
{
int i;
for(i=0; argv[i] != NULL; i++) {
	}
if (i != 6) {
	fprintf(stderr, "Wrong number of args (%d)\n", i);
	return 1;
	}
if (strcmp(argv[1], "-o") != 0) {
	fprintf(stderr, "argv[1] must be -o\n");
	return 1;
	}
if (strcmp(argv[2], "-a") != 0) {
	fprintf(stderr, "argv[2] must be -a\n");
	return 1;
	}
if (strcmp(argv[4], "-d") != 0) {
	fprintf(stderr, "argv[4] must be -d\n");
	return 1;
	}
setuid(geteuid());
setgid(getegid());

execv("/usr/bin/procmail", argv);
return 0;
}

On the VM I ordered gcc was already installed, so I just had to compile the source code on the ARM64 box.

wget https://github.com/virtualmin/virtualmin-gpl/blob/master/procmail-wrapper.c
gcc procmail-wrapper.c -o procmail-wrapper

That command produced the ARM64 executable.

Then:

Backup the original procmail-wrapper file
Copy new compiled binary file across
Fix permissions
Restart Postfix

mv /usr/bin/procmail-wrapper /usr/bin/procmail-wrapper.backup
mv procmail-wrapper /usr/bin/
chmod 4755 /usr/bin/procmail-wrapper
service postfix restart

Then to the see binary:

# file /usr/bin/procmail-wrapper
/usr/bin/procmail-wrapper: setuid ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=68e910c02bc6c2454e724027e14a210581af729f, for GNU/Linux 3.7.0, not stripped

johnheenan · 2023-07-17T11:44:27Z

Here is how I compiled and installed procmail-wrapper on ARM64. As mentioned in another post I'm very happy to donate an ARM64 VM to the Virtualmin staff for a year for testing.

Thanks @eugenefvdm. Very clear. I wasn't looking forward to trying to make sense of what the drama was about procmail-wrapper.

On an AMD64:

file /usr/bin/procmail-wrapper 
/usr/bin/procmail-wrapper: setuid ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 3.2.0, BuildID[sha1]=51e8e9a587270791d8ee31e4c74a0bb26e2f8469, not stripped, too many notes (256

apt-cache madison procmail-wrapper
procmail-wrapper |      1.1-3 | https://software.virtualmin.com/vm/7/gpl/apt virtualmin/main amd64 Packages
procmail-wrapper |      1.1-3 | https://software.virtualmin.com/vm/7/gpl/apt virtualmin/main all Packages
procmail-wrapper |      1.1-2 | https://software.virtualmin.com/vm/7/gpl/apt virtualmin/main amd64 Packages
procmail-wrapper |      1.1-2 | https://software.virtualmin.com/vm/7/gpl/apt virtualmin/main all Package

iliajie · 2023-07-18T23:47:37Z

There already was procmail-wrapper-arm64 package for Debian/Ubuntu and RHEL derivatives virtualmin/virtualmin-install#82.

johnheenan · 2023-07-19T00:44:36Z

There already was procmail-wrapper-arm64 package for Debian/Ubuntu and RHEL derivatives virtualmin/virtualmin-install#82.

Thanks @iliajie.

I confirm there is a PR from last January in a dev branch with packaging mentioned but the PR has not been accepted. There is now a conflict with the master branch.

Since the jailkit update in distos, it looks like jailkit can now come from standard distros and so does not need architecture specific packaging. The Webmin module part of jailkit is not architecture specific.

It looks like everything is set up for easy solutions with just a single package required (procmail-wrapper) for any supported architecture, other than for all architectures.

If an architecture is not supported, how about:

A post installation message and invitation to try a script if gcc is detected, based on @eugenefvdm's approach?
Include arch=all in line of /etc/apt/sources.list.d/virtualmin.list to prevent frightening and misleading messages when apt update or equivalent is used?

iliajie · 2023-07-19T00:50:28Z

I think jailkit ARM 64 package is still needed for RHEL repo, right @joe?

…

On Wed, Jul 19, 2023 at 3:44 AM johnheenan ***@***.***> wrote: There already was procmail-wrapper-arm64 package for Debian/Ubuntu and RHEL derivatives virtualmin/virtualmin-install#82 <virtualmin/virtualmin-install#82>. Thanks @iliajie <https://github.com/iliajie>. I confirm there is a PR from last January in a dev branch with packaging mentioned but the PR has not been accepted. There is now a conflict with the master branch. Since the jailkit update in distos, it looks like jailkit can now come from standard distros and so does not need architecture specific packaging. The Webmin module part of jailkit is not architecture specific. It looks like everything is set up for easy solutions with just a single package required (procmail-wrapper) for any supported architecture, other than for all architectures. If an architecture is not supported, how about: 1. A post installation installation message and invitation to try a script if gcc is detected, based on @eugenefvdm <https://github.com/eugenefvdm>'s approach? 2. Include arch=all in line of /etc/apt/sources.list.d/virtualmin.list to prevent frightening and misleading messages when apt update or equivalent is used? — Reply to this email directly, view it on GitHub <#593 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABBYWJO3G6UI6K563A6LEDTXQ4UX7ANCNFSM6AAAAAA2L44MHQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

swelljoe · 2023-07-19T00:56:36Z

Yes, jailkit is not in the OS or EPEL repos for RHEL-based distros.

johnheenan · 2023-07-19T21:58:48Z

So, why not drop a separate jailkit package for RHEL based distros and instead provide a link to a set of instructions as to how they can build (and update) jailkit themselves for use with webmin jailkit module?

I can understand the case for making procmail run as real user id root (instead of effective root with suid) through procmail-wrapper, in order to filter spam and so make procmail-wrapper into a package. Allows called virtualmin scripts called by procmail to run as root prior to running spamassasin? Spamassasin is a core service. But jailkit is not a core service.

Also using @eugenefvdm's approach would keep embedded users happy, like raspberry PI, orange PI and tiny router board users. However, it may not even be an issue for them if aarch64 (ARM64) is supported as I think they are now all aarch64. They have gcc available, or can get it as a small package without the unnecessary accompanying build environment and build libraries. They are not going to care about jailkit and care even less about RHEL based distros.

johnheenan · 2023-07-19T23:15:52Z

For unsupported architectures where gcc is not installed and so installing procmail-warpper becomes an inconvenience or fraught with potential issues, would the following work instead?

Run spamassassin through its client/server form with spamc/spamd instead?

swelljoe · 2023-07-20T05:19:53Z

Jailkit already includes a spec file in the source distribution, for folks who want to build an RPM themselves (and I provide an SRPM with our minor changes/updates if you want it to be even easier).

Run spamassassin through its client/server form with spamc/spamd instead?

You can process mail any way you want to. Virtualmin and Webmin support several methods. But, the Virtualmin installer sets up procmail in a way that allows every user and every domain to have custom processing, based on their needs. Without procmail-wrapper and procmail, Virtualmin and Usermin can't manage stuff like forwards and auto-responders.

johnheenan · 2023-07-20T06:52:12Z

Thanks everyone for your comments.

I think this is the right time to close this issue on GitHub, not because it has been resolved but because:

A lot of the main points have been covered, with a link to more.
Workarounds have been covered.
A GitHub PR is not going to finalise these issues.
Installation and distribution are not 'code only'
Policy decisions with regard to installation and distribution are not suitable for a GitHub issue.

johnheenan · 2023-07-21T08:55:36Z

Closing issue now for reasons above.

The code quality of Virtualmin is high. It's core language, Perl, is not used in an obscure manner. The overall design is highly modular and is also good. The packaging can be improved.

A constant complaint is that the documentation is poor. However, Virtualmin is highly hands on. To a certain extent learning to use Virtualmin is like learning to drive car. You don't learn to drive a car from reading a manual and learning is an awkward and stumbling experience at first. The more experience you get the smoother the experience becomes.

If you want to understand how Virtualmin works you need to read source code.

The Virtualmin team deserve to be highly regarded for keeping their very high-quality project running in what appear to be lean times.

This issue was linked to the end of the following two posts

johnheenan closed this as completed Jul 21, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Simplifying repositories and eliminating 'doesn't support architecture' message with Debian and derivatives on ARM64 #593

Simplifying repositories and eliminating 'doesn't support architecture' message with Debian and derivatives on ARM64 #593

johnheenan commented Jul 16, 2023 •

edited

Loading

eugenefvdm commented Jul 16, 2023

jcameron commented Jul 16, 2023

swelljoe commented Jul 16, 2023

swelljoe commented Jul 16, 2023

eugenefvdm commented Jul 17, 2023 •

edited

Loading

johnheenan commented Jul 17, 2023 •

edited

Loading

iliajie commented Jul 18, 2023

johnheenan commented Jul 19, 2023 •

edited

Loading

iliajie commented Jul 19, 2023 via email

swelljoe commented Jul 19, 2023

johnheenan commented Jul 19, 2023 •

edited

Loading

johnheenan commented Jul 19, 2023

swelljoe commented Jul 20, 2023

johnheenan commented Jul 20, 2023 •

edited

Loading

johnheenan commented Jul 21, 2023

Simplifying repositories and eliminating 'doesn't support architecture' message with Debian and derivatives on ARM64 #593

Simplifying repositories and eliminating 'doesn't support architecture' message with Debian and derivatives on ARM64 #593

Comments

johnheenan commented Jul 16, 2023 • edited Loading

eugenefvdm commented Jul 16, 2023

jcameron commented Jul 16, 2023

swelljoe commented Jul 16, 2023

swelljoe commented Jul 16, 2023

eugenefvdm commented Jul 17, 2023 • edited Loading

johnheenan commented Jul 17, 2023 • edited Loading

iliajie commented Jul 18, 2023

johnheenan commented Jul 19, 2023 • edited Loading

iliajie commented Jul 19, 2023 via email

swelljoe commented Jul 19, 2023

johnheenan commented Jul 19, 2023 • edited Loading

johnheenan commented Jul 19, 2023

swelljoe commented Jul 20, 2023

johnheenan commented Jul 20, 2023 • edited Loading

johnheenan commented Jul 21, 2023

johnheenan commented Jul 16, 2023 •

edited

Loading

eugenefvdm commented Jul 17, 2023 •

edited

Loading

johnheenan commented Jul 17, 2023 •

edited

Loading

johnheenan commented Jul 19, 2023 •

edited

Loading

johnheenan commented Jul 19, 2023 •

edited

Loading

johnheenan commented Jul 20, 2023 •

edited

Loading