AWS Thinkbox Discussion Forums

[Solved] [Linux] Launcher won't run under certain users

Hello!

I’m in the process of setting up a small farm at my university. The blades are running CentOS 7.4 and I’m having some user difficulty. When installing the client, I have chosen to use an alternate, non-sudo user (nuser) for running the processes under. This is also installed as a daemon.

When running, the launcher and slave start but don’t connect to the repository. If I switch from nuser to my current actual sudoer user (suser) in the init script, the connection is then made. I have also tried to use a nologin user (editing the init script to include -s /bin/bash) to no avail either.

Is it necessary to run as a sudo capable user? The only other thing I can think of is that the SSL certificate is in the /home/suser directory and is owned by that user, but I’m not sure that’s it.

Cheers,
Mike

Not sure if Deadline version will matter here, but it would be good to know just in case.

The Launcher log is usually pretty helpful here, so if you could grab that from “/var/log/Thinkbox/Deadline[Version]” that would be appreciated.

Are you doing a network install here? The Launcher is going to try and make a few home folders and read the ini file at “/var/lib/Thinkbox/Deadline[Version]/deadline.ini” so that’ll be something to check out as well.

Log and deployment information I think are going to be the most helpful bits.

Hi E,

Thanks for the pointer to the log file. I removed my previous new user and made a standard system user. The log was showing that the SSL certificate didn’t exist (couldn’t read from another home directory); copying it to the new user’s home directory solved that problem and it connects fine now.

I’m using Deadline10. Is it even possible to use nologin users to run the daemon?

Cheers,
Mike

Actually, it’s unlikely that it will. If you’ll see in the init script we actually start a shell session to injest all of the profile settings.

You might be able to hack it to make it work, but I’m not sure what new problems would surface.

That’s what I figured. I tried hacking the init script a bit (adding in [b]- -s /bin/bash[/b] where it’s necessary) but it didn’t seem to like it that much. The concern for this is just security, this is a semi-public box at a university, so I try to keep the amount of login users to a minimum. The fix for this atm is just rejecting the user’s ssh attempts.

Cheers,
Mike

Sounds good to me.

Privacy | Site terms | Cookie preferences