Shell script help: change to root mid script

[djbon2112]

Even in this scenario, creating a group would work. All server files (regardless of where they are or what server they belng to) would be owned by root and the "gameadmin" group. I know setting this sounds tedious, but believe me when I tell you it takes less than five minutes with a small recursive command.
Every one of this files would have the read/write/execute bit enabled for their group members.

In case I'm misunderstanding you and you really can't do it that way, there is yet another option you have:
Create a program to control any possible routine your helpers would have to perform (python/perl/bash may be good languages for this), it doesn't have to be very complicated, in fact since it will be used through SSH it can be a very simple console program. Then give your helpers the ability tu run only THAT program with root capabilities by using visudo.

The downside, of course, is that you'd have to know at least some very basic programming (or know someone who does), but your helpers would be limited to the tasks the program offers, thus achieving a relatively decent setup security-wise...

If you give some examples of some of the things they would be doing on the server (edit config files, restart the connections, IP-banning players?), maybe we can come up with something more concrete.

The problem with the first idea is that I don't know which game servers we'll be running, and all of them tend to be different (have config files in different places, different binaries, need to access different things). I can't write a script to control an application and its files if I don't know what application it will be And it comes back to me not wanting to do this myself AT the event, which is the time the games to play is usually proposed (as I said, we're kinda free-for-all). I hope that makes sense! I can do basic programming in a bunch of languages so that's not a problem for me.

What any given game server admin might need to do:

* Install the game server software
* Start/stop/restart the game server service(s)
* Modify config files for the game server
* Execute any binaries for the game server (this usually takes care of banning players, modifying maps, etc.)

Thanks for your help amingv, I do appreciate it!

EDIT: I also crossposted this on [H]ardforum (I frequent there too), so here's that thread. Having to rewrite it all in one post makes my reasons and such a bit clearer, I think

[amingv]

The problem with the first idea is that I don't know which game servers we'll be running, and all of them tend to be different (have config files in different places, different binaries, need to access different things). I can't write a script to control an application and its files if I don't know what application it will be And it comes back to me not wanting to do this myself AT the event, which is the time the games to play is usually proposed (as I said, we're kinda free-for-all). I hope that makes sense! I can do basic programming in a bunch of languages so that's not a problem for me.

What any given game server admin might need to do:

* Install the game server software
* Start/stop/restart the game server service(s)
* Modify config files for the game server
* Execute any binaries for the game server (this usually takes care of banning players, modifying maps, etc.)

Thanks for your help amingv, I do appreciate it!

EDIT: I also crossposted this on [H]ardforum (I frequent there too), so here's that thread. Having to rewrite it all in one post makes my reasons and such a bit clearer, I think

OK, now we're speaking plain english!
I though you were going to host a permanent game server (I once did this with eAthena, so my mind went right there when I read your problem.), that's why I though the other people using them would be your "helpers" or "subordinates"

Asuming the server machine has some decent memory, you could run several Virtual Machines, that way each can have their own IPs (no server stealing each other's ports), and if somebody screws up (unintentionally or otherwise) it will not affect the other VMs at all.

You could also run sandboxes, but the servers may not get all the resources they need.

You could also create a queue list, have them write the path to their server executable there, and have another routine (like cron) execute everything on the list every minute as root and flush it (can provide a hole to security, unless you filter malicious commands in the list) If they install the games in their home folders (which is doable) they will also be able to edit config files. It may be tricky to make it work well, though.

I know there must be smarter ways to do this, I'll see if I can offer you anything else tonight (after I come back from college).

[djbon2112]

OK, now we're speaking plain english!
I though you were going to host a permanent game server (I once did this with eAthena, so my mind went right there when I read your problem.), that's why I though the other people using them would be your "helpers" or "subordinates"

Asuming the server machine has some decent memory, you could run several Virtual Machines, that way each can have their own IPs (no server stealing each other's ports), and if somebody screws up (unintentionally or otherwise) it will not affect the other VMs at all.

You could also run sandboxes, but the servers may not get all the resources they need.

You could also create a queue list, have them write the path to their server executable there, and have another routine (like cron) execute everything on the list every minute as root and flush it (can provide a hole to security, unless you filter malicious commands in the list) If they install the games in their home folders (which is doable) they will also be able to edit config files. It may be tricky to make it work well, though.

I know there must be smarter ways to do this, I'll see if I can offer you anything else tonight (after I come back from college).

I was originally thinking VMs too, but then I got this idea and figured "hey, that's easier!". Well, I guess not! I managed to solve the IP logging issue, but for what it's worth I think I may just abandon this and do the VMs thing. Should be easy enough to script their creation (so I only have to type in my password once, if at all), let the person doing it set their own root password, and go from there. It will be a pretty powerful server so that's not an issue!

Thanks again amingv, I'll leave this thread open if anyone else has suggestions/improvements. I did GPL the script and publish it

[scorp123]

I may just abandon this and do the VMs thing. Should be easy enough to script their creation

With VirtualBox, Xen, and I think KVM too you can certainly do that.

VirtualBox has the "VBoxManage" command. If you just type "VBoxManage" without giving any options it will spit out all the options it knows, and amongst these are things like "createvm", "modifyvm", "startvm", "controlvm" ... So given the right arguments and parameters you can easily script and automate all the VM creation steps.

[djbon2112]

With VirtualBox, Xen, and I think KVM too you can certainly do that.

VirtualBox has the "VBoxManage" command. If you just type "VBoxManage" without giving any options it will spit out all the options it knows, and amongst these are things like "createvm", "modifyvm", "startvm", "controlvm" ... So given the right arguments and parameters you can easily script and automate all the VM creation steps.

I've yet to use VirtualBox for server virtualization (only desktop w/GUI): how well does it perform, assuming everything is Linux (host and VMs), versus Xen? I'd probably use one master virtual disk image and just copy it for each VM needed, then delete the modified copy when done. I know I can do this fine with both.

[scorp123]

I've yet to use VirtualBox for server virtualization (only desktop w/GUI): how well does it perform, assuming everything is Linux (host and VMs), versus Xen?

Xen clearly has the speed advantage on its side. No argument. If you run Linux-on-Linux then Xen is the clear winner performance-wise. What VirtualBox has in its favour is the ease-of-use ... e.g. you could prepare a VM on your laptop, then just export it and import it again on your server. Done. It will work. And I don't know if Xen is able to take snapshots of VM's? VirtualBox certainly can. If anything goes wrong you go back to the last working snapshot. So if ever anyone hoses their setup ... you go back to the snapshot. Done. As I said: no idea if Xen has such mechanisms too?

[amingv]

I was originally thinking VMs too, but then I got this idea and figured "hey, that's easier!". Well, I guess not! I managed to solve the IP logging issue, but for what it's worth I think I may just abandon this and do the VMs thing. Should be easy enough to script their creation (so I only have to type in my password once, if at all), let the person doing it set their own root password, and go from there. It will be a pretty powerful server so that's not an issue!

Thanks again amingv, I'll leave this thread open if anyone else has suggestions/improvements. I did GPL the script and publish it

I'm glad you found a suitable solution to this dilemma .
If you need any further help, please do not hesitate to ask , we'll all see what we can do.

P.D. Where did you publish the script, by the way? I'd like to have a look, if it's OK.

[djbon2112]

On the first page, 3rd or 4th post I think. I updated it so it's in the "done" state right now.