Yes, I know. This is the safest way. Maybe Xen is more powerful. But in a chrooted/virtual environment symlinks doesn't work. I didn't like to install every GS as a standolone version. Big providers can't live without symlinks. Maybe hardlinks are an option, but they are not easy to handle. In Debian there is a package called schroot. You can chroot with a normal user and build the environment with debootstrap or makejail. But there is the problem, that will every installation will take a while. A symlinked server can be installed in 3 seconds. Can you do this with a chrooted environment + installation of the server?
Show me an example with chroot + working symlinks. 2011/1/21 Kacper Nowak <[email protected]>: > It can be done by using chroot in server dir. Some startup script > modification is required, but its simple. > > regards > KN >> >> Its not fine :-D >> There are much more problems, which come out when the permissions >> aren't correct. >> Maybe running servers own with one user is ok. For providers it will >> make sense to create for every customer/server one user. >> I know there are some provider who handle it with a single user. It >> isn't easy to tell a big old script, which have 1000 of functions to >> work with users after a little code change. So they cant change it >> without spend much time for coding. >> >> 2011/1/21 Saul Rennison<[email protected]>: >>> >>> I thought of the rcon issue previously but I forgot to bring it up. >>> Massive problem that some people on this list thing that all customers >>> on one user is fine. >>> >>> On Friday, 21 January 2011, Joonas Lehtolahti >>> <[email protected]> wrote: >>>> >>>> The point isn't really that plugins can be loaded from elsewhere. No, >>>> that isn't needed, but the real problem is bigger than that. The srcds >>>> process has as much access as the user/group it is running as. If a user >>>> can >>>> upload a plugin to be used on that server, that plugin also has all the >>>> privileges as the host srcds process has. That is, it can go for example >>>> check the rcon_password variables from config files of other customers' >>>> installations if they are installed with the same user account. That as a >>>> simple example. If a customer should not be able to access the files of >>>> other customer, then their processes must be run with different local user >>>> accounts. >>>> >>>> >>>> On Fri, 21 Jan 2011 18:48:18 +0200, Andre >>>> Müller<[email protected]> wrote: >>>> >>>> >>>> You all think it's ok, when the server can load plugins from anywhere. >>>> Do you need this? Tell me why. >>>> >>>> In example one provider have one user for all gameservers on a host. >>>> Every customer gets chrooted FTP-Access (virtual users) to his own >>>> serverdirectory. So he/she can't access to the other directories. I >>>> know you like it more complex and want for everey gameserver his own >>>> user. Nice, safty first. >>>> Then is the next problem to get the screen for an different user to >>>> his gameserver for debuging. Maybe sourcemod hangs or something else. >>>> >>>> When you like hacks, you can execute as root: >>>> >>>> chmod 666 `tty`; su -c "screen -r css_27015" customer123 >>>> >>>> A little nice hack. I know you can use shared screen sessions. You >>>> like more complexity. >>>> >>>> Third example: You are using Teklab and your customer have two >>>> gameservers. So the customer can access to his two gameservers, when >>>> they are on the same host. In this situation the customer can load >>>> plugins from his second gameserver. There are many mini hosters who >>>> uses this. >>>> >>>> You really want to tell me, that you ever have loaded Plugins from >>>> outside the serverdirectory? >>>> plugin_load "/home/plugins/zBlock/zblock" >>>> I don't have tested it until yet, where the server after this writes >>>> the logfiles for zblock. Maybe in your addons-directory or outside in >>>> /home/plugins/zBlock/zb_logs/? >>>> >>>> I think its easier and safer to use for this way symlinks. The safest >>>> way is, to block only loading plugins, which aren't located in servers >>>> directory, but don't break the support for symlinks ;-) >>>> >>>> 2011/1/21 Marco Padovan<[email protected]>: >>>> >>>> Agree to this :| >>>> >>>> Why can a single user access to another customer dir? >>>> I can understand maybe to /tmp or things like that... but another >>>> customer >>>> dir?? :/ >>>> >>>> Il 21/01/2011 09:40, Marcel ha scritto: >>>> >>>> >>>> If the provider really allows access to other customer directories he >>>> should stop renting servers and do his homework first. >>>> This is really no job for Valve. >>>> >>>> >>>> _______________________________________________ >>>> To unsubscribe, edit your list preferences, or view the list archives, >>>> please visit: >>>> http://list.valvesoftware.com/mailman/listinfo/hlds_linux >>>> >>>> >>>> _______________________________________________ >>>> To unsubscribe, edit your list preferences, or view the list archives, >>>> please visit: >>>> http://list.valvesoftware.com/mailman/listinfo/hlds_linux >>>> >>>> >>>> >>>> _______________________________________________ >>>> To unsubscribe, edit your list preferences, or view the list archives, >>>> please visit: >>>> http://list.valvesoftware.com/mailman/listinfo/hlds_linux >>>> >>>> >>>> _______________________________________________ >>>> To unsubscribe, edit your list preferences, or view the list archives, >>>> please visit: >>>> http://list.valvesoftware.com/mailman/listinfo/hlds_linux >>>> >>> -- >>> >>> Thanks, >>> - Saul. >>> >>> _______________________________________________ >>> To unsubscribe, edit your list preferences, or view the list archives, >>> please visit: >>> http://list.valvesoftware.com/mailman/listinfo/hlds_linux >>> >> _______________________________________________ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> http://list.valvesoftware.com/mailman/listinfo/hlds_linux > > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlds_linux > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
