3

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.
  • 1
    If you echo $PATH locally and via SSH, are they the same? – Allan Mar 5 at 13:28
  • 1
    Yes, the output is '/Library/Frameworks/Python.framework/Versions/3.7/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin' both in screen sharing and on ssh. – MokaT Mar 5 at 17:02
  • 1
    Please post the contents of your ~/.bash_profile and ~/bashrc to your original question. – Allan Mar 5 at 20:26
  • 1
    Done (this is jenkins builder) – MokaT Mar 6 at 7:49
  • 1
    Which one is that for? Those are different files and read in different instances. – Allan Mar 6 at 12:19
1

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.

  • Hi bmike. Unfortunately I ran into a very similar issue just with tmux on my local machine, so I don't think this will help here. If they fix something, you can check it out in my bug report here: github.com/tmux/tmux/issues/1847 – Christopher Apple Jul 18 at 22:10
  • 1
    That’s disappointing @ChristopherApple - I’m glad you mentioned this and will follow for updates. I would upvote your answer if you want to make the above into one. It might help others find the issue – bmike Jul 19 at 1:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .