Feature: Allow arch selection/force during pro attach

[Monochromics]

Please describe the scenario where the new feature would be useful

Occasionally users would like to only enable amd64 packages on given clients. This is particularly relevant when using an on-prem contracts server where space may be limited and i386 packages are not mirrored.

Describe the solution you'd like

On pro attach, it would be nice to allow for --arch to only set up repositories for a given arch. Setting an overall APT:: conf does seem to work in focal+, but not in older series. Alternatively, a non-fatal error that allows attachment would be fine.

Current behavior

If your repository mirror does not contain i386 packages and you're using an on-prem contracts server (with an override for the repositories provided), pro enable esm-apps will fail. The logged error suggests an apt proc (sep issue) is running, but if you manually increase logging, you can see it fails when the i386 Packages file 404s. This then unloads the gpg key and fails the service enablement.

[renanrodrigo]

Hello, @Monochromics , thanks for reporting this.

I'm curious on the error itself because the Pro Client does not deal with arches at all. So besides a flag, a whole new piece of functionality would be needed to sort this out...

I see you included a general scenario, but would you have steps to reproduce those errors? It would be nice to see what the repository contains. My guess is that the mirroring could be done wrong - if you are only getting the amd64 binaries to the mirror, the Release file needs to be different, ideally re-generated based on those packages only. If it contains information about any other architecture and your system has this architecture, it will try to look for those and correctly error out IMHO.

Another thing that got my attention is the APT::conf change you mentioned. Could you share which key/values are you changing exactly, so we can further investigate why it does not work on older releases? APT configuration should be respected and work anywhere.

[Monochromics]

Hey @renanrodrigo ,

That's fair. I think the core problem is that a lot of people use apt-mirror as a mirroring tool, and my default it does not mirror the i386 items (as just deb in mirror.list does not behave the same as it does in your sources, and only pulls amd64 packages). So it's reasonable to say that they should be adjusting and re-signing Release if they're making an explicit choice to save space.

On the other hand, I'm not sure that the pro client should abort the service enablement due to the i386 Release file missing when calling apt update. This would at least slightly be alleviated if the logged error was useful, but currently any apt failure is logged as assuming another apt process is running.

This can be worked around to get the actual output by modifying /usr/lib/python3/dist-packages/uaclient/apt.py:

def update_sources_list(sources_list_path: str):
......
        try:
            with lock:
                cache.update(fetch_progress, sources_list, 0)
        # No apt_pkg.Error on Xenial
        #except getattr(apt_pkg, "Error", ()):
        #    raise exceptions.APTProcessConflictError()
        except getattr(apt_pkg, "Error", ()) as e:
            LOG.debug(f"Encountered error: {e}")
            raise

---

Reproducing all of this is a bit of a journey but basically you just need to:

• grab the ua-airgapped tools from the yellow/ua-airgapped ppa
• gen a bearer token
• install apt-mirror and set up mirroring for esm-apps using the above bearer (with only deb, not deb-i366)
• conf your override.yaml to set up the esm-apps url and start the contracts server
• attach a client with --no-auto-enable after pointing it to the new contracts server
• pro enable esm-apps

You should just get that generic apt process is running msg unless the above changes to apt.py are made, but with those you'll see it exits when it notices the release file is missing.

This occurs even if the global apt override I mentioned is set (presuming I'm using it correctly):

:~$ cat /etc/apt/apt.conf.d/00arch
APT::Architecture { "amd64" };

At least in bionic. It may be honored in more recent releases of apt.

So to conclude, while this isn't really a true pro client issue, if there was an option to attach a machine and have the source set as something like:

deb [ arch=amd64 ] $restoftheline

instead (or just not fatally fail on apt update during attachment), it would avoid a number of potential pitfalls.

[renanrodrigo]

but currently any apt failure is logged as assuming another apt process is running.

Yeah this is horrible we need to improve the reporting there definitely.

I'm not sure that the pro client should abort the service enablement due to the i386 Release file missing when calling apt update.

Me neither, thinking about it. That is a little trickier to decide. Technically we could ignore it, but all apt update calls after that will fail too, and we know by experience that if running a pro command breaks (or even inadvertently changes) apt or other tools' behavior, then pro gets all the hate under the spotlight for doing things wrong :D :D

while this isn't really a true pro client issue (...) it would avoid a number of potential pitfalls.

This is fair. I don't see we adding any flags, but I can see we adding a warning on enablement and continuing. I'll investigate further when I get some time to.