I'm at a loss with rc.local and specific users

[FlyingMongoose]

I'm still fiddling with letting screen run via su...but after looking into the man...
screen = a shell instance...
su = a shell instance...
runuser = a shell instance...

This could be the issue here...but I'm still trying to figure it out. I believe I have an idea how to make su/runuser work though. (probably just su).

Yes I know you've been meaning to update the guide; hopefully me posting this gave you a little kick start; I mean you pretty much have all the documentation right here for a resolution.

[Edge100x]

Yes I know you've been meaning to update the guide; hopefully me posting this gave you a little kick start; I mean you pretty much have all the documentation right here for a resolution.

It's not hard to do and I can whip it up pretty quickly (then and now), but I just haven't had a chance. Too busy on time-critical tasks like responding to customer questions. Story of my life!

[FlyingMongoose]

If you want I'll do it for you; that way all you gotta do is copy and paste a response from here. I've got nothing but time lately (but it will have to wait until sometime tomorrow).

Like I said I'm trying to get screen to run under su still.

[FlyingMongoose]

got it! Another access rights issue;

screen utilizes /dev/pts/; also not accessible to the user

So I recursively did a chmod to /dev/pts/

I'm now running the following command lines

chrt -r 20 su - servers -c "cd /usr/steam/sourcebase/orangebox/ && screen -AmdS screenname ./srcds_run -game cstrike +ip xxx.xxx.xxx.xxx +maxplayers xx

chrt -r 20 su - servers -c "cd /usr/steam/hldsbase/ && screen -AmdS screenname ./srcds_run -game cstrike +ip xxx.xxx.xxx.xxx +maxplayers xx -pingboost 2

So essentially to resolve the issue chmodding /dev/pts/ (for screen) recursively and chmodding /usr/steam/ recursively resolves the issue.

[FlyingMongoose]

Whoops fix to second part here

Code: Select all

chrt -r 20 su - servers -c "cd /usr/steam/sourcebase/orangebox/ && screen -AmdS screenname ./srcds_run -game cstrike +ip xxx.xxx.xxx.xxx +maxplayers xx

chrt -r 20 su - servers -c "cd /usr/steam/hldsbase/ && screen -AmdS screenname ./hlds_run -game cstrike +ip xxx.xxx.xxx.xxx +maxplayers xx -pingboost 2

[FlyingMongoose]

First off you need to add a user; you can do this either via a GUI (if your server has one via VNC) or you can do it in a terminal or shell prompt with the following commands after logging into "root".

1. Adding a user

   Code: Select all

   adduser USERNAME
   passwd USERNAME

   Replacing "USERNAME" with the username you wish to add.
   "adduser" creates the user
   "passwd" lets you set the user's password (this *must* be run otherwise your user can't log in!)
2. Installing "screen"
   This is pretty straightforward; and it depends on the distro; you may not need this

   Code: Select all

   yum install screen

3. OPTIONAL (but suggested): sudoers
   Next step is add this new user to "sudoers"
   
   Sudo is a "more secure" form of "su" (so you don't need to give out root password if you ever want someone to have SSH)
   
   If you don't have sudo installed you use the following command for CentOS

   Code: Select all

   yum install sudo

   Then open up /etc/sudoers in your favorite text editor and find the following line.

   Code: Select all

   root    ALL=(ALL)       ALL

   Add a new line below this and add the following

   Code: Select all

   USERNAME    ALL=(ALL)       ALL

   Obviously replacing "USERNAME" with the user you created above.
   
   Close and save.
4. Changing access right
   • This assumes you used the pre-install provided by NuclearFallout on your Dedicated server of VPS
   Execute the following line in your shell or terminal

   Code: Select all

   chmod -R 777 /usr/steam

   NOTE: This should probably be chown but I can't seem to change the ownership to the user in my server right now so I went with the simplest solution I knew.
   
   This gives access to the "/usr/steam" directory to any user on your server
   
   Next is the issue (in some cases) of "screen" not being allowed by users via the "su" command. So we execute the following command.

   Code: Select all

   chmod -R 777 /dev/pts

5. Adding to rc.local
   
   Open up the file "/etc/rc.local" in a text editor
   
   Add the following line

   Code: Select all

   chrt -r 20 su - USERNAME -c "cd /usr/steam/sourcebase/orangebox/ && screen -AmdS SCREENNAME ./srcds_run -game cstrike +ip xxx.xxx.xxx.xxx +maxplayers xx

   Replacing "USERNAME" with the name you created in step one and replacing "SCREENNAME" with the name of the screen you wish for the
   
   Save and close the text file
6. Feel free to restart your server to see if it worked.

This should now run your game server on bootup (I personally use one user for an HLDS and srcds).

If you wish to view your servers from ssh or a terminal log into the user you created in the first step and type

Code: Select all

screen -ls

This will show the list of screens you have running on this user

You should be able to "resume" the screen session by typing the following

Code: Select all

screen -Dr SCREENNAME

or

Code: Select all

screen -Dr pid

pid is the number it shows in screen -ls next to scren name; this can be necessary if lets say you have two "screens" 1 named "cs" and the other named "css"; screen by default searches for ANY screen string that matches; so if you try to do screen -Dr cs it'll show that there are two like that; (so I suggest adding a number; e.g. cs1).

If you wish to "detach" the screen you can press CTRL+A then CTRL+D and it will keep the screen (and your server running); if you wish to close the screen you can press CTRL+C.

If you've closed all your servers and wish to boot them all back up you can run the following command from root

Code: Select all

cd /etc/
./rc.local

However we set up sudo; so from the user created in step 1 you can do this as a sudo command.

Code: Select all

cd /etc/
sudo ./rc.local

It'll ask you to re-input your user's password (NOT root). If you succeed in the password the command will be executed and the servers restarted.

[FlyingMongoose]

I got bored....so there's your tutorial...obviously can be modified slightly for hlds...

[Edge100x]

Nice, thanks!

I'm not sure of the potential security repercussions from a chmod of /dev/pts* files, so I will have to check into that -- suid on the screen binary might work better. (Personally, I prefer having all my screens run under root, anyhow.)

chown'ing /usr/steam would be important if you have other users on the machine, such as web users, but would also need to be coupled with a chmod change to achieve a properly secure environment.

[FlyingMongoose]

Yes, I do know the security repercussions of this; however if you do actually have web users you should also have security in place for those web users too, to keep them from going "outside their folders" in the first place...

[Edge100x]

Yes, I do know the security repercussions of this; however if you do actually have web users you should also have security in place for those web users too, to keep them from going "outside their folders" in the first place...

I take it that you mean via a chroot for Apache, all the web users, and all of the support libraries and applications? That's potentially doable but far from the norm, and not really needed. The standard is to have permissions for each folder on the machine set correctly such that only authorized users can access them, and to potentially have some additional security measures enabled in the kernel.

[FlyingMongoose]

I don't deny that; I'm just saying it's one more layer that if you DO have web users should be there...

[Edge100x]

That people should be using chroot for webhosting? I wouldn't agree with that. It's a massive amount of hassle, and doesn't add much security -- if you truly don't trust the Linux kernel to enforce the permissions on a folder, a chroot shouldn't give you much peace of mind. At that level of paranoia, you should be putting each website onto its own VDS.

[FlyingMongoose]

We both know people who do that I'm sure...