Auval and Auvaltool not working through SSH

I was successfully validating audio unit plugins with OSX 10.11 over SSH. On my new machine which runs OSX 10.14 (Mojave) everything works fine until I try to validate a plugin from an SSH connection. I use the same command in the same directory both in local and over SSH.

/usr/bin/auvaltool -v aumf MyPl Loco

The thing is, using SSH, auval do not detect my plugins (/usr/bin/auvaltool -a), but only Apple default ones. When doing the same on the screen sharing, my plugins are in the output.

• This does not seems to come from $PATH.
• This does not seems to come from permission (I have tried a chmod 777 on every .component)
• This does not seems to come from group/user (I have tried to chown it to diferent user)
• This does not seems to come from administration (I have tried to sudo it)

So my question is, do you know any SSH security limitation that can break my execution of auval and auvaltool ? What can be different on SSH that could make some execution behaviour changes ?

Thanks.

EDIT: How to reproduce ?

• Install any non-apple AU plugin.
• Launch a terminal and:
  • "auval -a" will output the previously installed plugin.
  • "ssh localhost" will connect to you machine through SSH
  • "auval -a" will NOT output the previously installed plugin.

Solution 1:

I found another workaround which is still not pretty, but less invasive. I implemented a small python-http server which expects the auval arguments as url-get parameters. If this python-server now is started using a non-ssh session, it is possible to validate all plugins using the http-get call. Below is the code for the small server.

from http.server import HTTPServer, BaseHTTPRequestHandler
import subprocess
from urllib.parse import urlparse, parse_qs

import traceback


def run_auval(params):
    arguments = ["auval", "-v", params["type"], params["subtype"], params["manufactor"]]
    print("Running AUVal: {}".format(arguments))
    process_return = subprocess.run(arguments, capture_output=True)
    return process_return.stdout + process_return.stderr, process_return.returncode


class SimpleHTTPRequestHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        raw_params = parse_qs(urlparse(self.path).query)
        params = {}
        for key, value in raw_params.items():
            params[key] = value[0]

        try:
            output, return_code = run_auval(params)
        except:
            self.send_response(500)
            self.end_headers()
            self.wfile.write(str.encode(traceback.format_exc()))
            return

        self.send_response(200)
        self.end_headers()
        self.wfile.write(output)


if __name__ == "__main__":
    httpd = HTTPServer(("0.0.0.0", 8000), SimpleHTTPRequestHandler)
    httpd.serve_forever()

You can then use wget or an equivalent from an SSH session to get the result of au validation.

With the server running, output goes to auval_log.txt where you can search for FAILURE or SUCCESS:

wget "http://localhost:8000?type=aufx&subtype=Abcd&manufactor=Dlby" -O auval_log.txt

This is equivalent to running

auval -v aufx Abcd Dlby

but without the SSH issues

Solution 2:

This is a long shot, but I once had to install tmux with brew install tmux (and I already had https://brew.sh set up and ready to run) so that I could graphically log in and establish a terminal session for the user in question.

With fast user switching, you can then return to the log in screen - leaving that one user console session blessed with full GPU and full graphical console permissions and then ssh in to attach to the existing TMUX sessions.

Hopefully someone has a more direct answer, but after several days of bounties and some great comments trying to back into the answer, I wanted to get on the record that a graphical log in does have higher powers and permissions and you just might need that for now if no-one has a better fix for this.

Solution 3:

There is definitely a bug in OSX 10.14 and higher. Since Apple seems not in the way to fix it, I'll post the workaround as an answer.

The workaround here is to copy the AU components you need to validate through SSH in /System/Library/Components/, and then sudo killall -9 AudioComponentRegistrar in order to force a rescan on the next auval run.

For this, you will need to disable System Integrity Protection which forbid you to change the System directories.

Just for you know, AudioComponentRegistrar is a deamon, but auval is launching it if needed.

Note that you can find some nice information in this gist (it explains a workaround for iTerm2 users too).