Adding members to the development team of a shard.

[Yukiko]

No, this is not a "Help Wanted" sign for people to apply for positions on my staff. Though I am always open to hear from people interested.

This is more of a general question about script security etc. when bringing new scripters on to a project. How do those of you with teams of people who need access to some or all of your source/data/cfg files determine whether someone is a good risk to place them in such a position? How do you maintain security of sensitive files in the shard directory and still allow access to the files that your development team needs to work with?

[Marilla]

First, is a very big issue of trust, with me. Under NO circumstances at all would I accept someone to be a scripter who has not already been a staff member on my shard for some time, and who has shown that they are completely trustworthy, and have the proper aptitude. In turn, I also do not accept ANY staff members who have not been players for a long time, and who did not show aptitude and trustworthiness as a player. Finally, I don't bring people on as staff (and, therefore, scripter) if they've ever asked to do it. To me, the best candidates for staff and scripters are people who have the abilities and creativeness, but who really don't want to do it... people who have to be talked into it by having it explained to them what cool things they could accomplish, over and above what they already do as players.

I know your question was not about picking staff members, but to me, a scripter is simply something of a specialized staff member, that in some ways, has higher access. So, just as I would never accept a player 'off the street' to be a staff member, I would also never accept anyone 'off the street' to be a scripter, either. I think this is something that lots of shard admins really go wrong on, with both staff and scripters, so I'm taking a lot of time to go into it; but I think trust takes time to earn, and I think it's only valid to earn it when they don't know they are 'acting' for an evaluation to come in the future. So, for us; every person we've ever asked to be staff or to help with scripting, it is always someone who never breathed a word of it themselves.



Once you do decide to give someone some access to work on scripting and such, there are a couple of what I feel are 100% iron-clad rules, and then there are some 'steps' as far as how to let them in to things.


Rules rules rules!

Don't give them access to the operating system. Ever. Do not give them the ability to have a full, interactive login on the server. Whatever operating system you are using, you can carefully assign them their own, unique user login, and then give that login only the exact rights they need to do their job. In fact, I recommend that you actually have that be nothing at all. That is, I recommend your scripters do not have ANY direct access to your server at all, but instead, you give them the files that need separately, and they send you their completed work. Personally, I have never gone beyond that level of access with anyone.

But if you do choose to give them some direct access, (or, for deciding what information you should send them...) here are some guidelines about what they should not have access to.

They should not have any rights to overwrite executable files. They don't need to be touching the pol, uoconvert or ecompile binaries. Perhaps they can have execute-only privs on uoconvert or ecompile, assuming you've decided to give them that level of access, but they should never have write permissions to it. No matter what operating system you are on, it's elementary to limit access to files (specific, or a whole directory) based on users.

They should never have even read-only rights to the data directory. Whether by accident, ignorance or purpose, they can really - pardon my language - but screw your shard with such access. Even with read-only access; You may think that because you don't store passwords in the account file, for instance, that you have nothing to fear there. But most people use trivial passwords for their account, and while no one is going to be able to figure out the password from the hash info, they can do something much easier: take a hacking dictionary, and apply the hashing algorithm to it. For example, take the word 'password', hash it using the same algorithm that POL uses, and see if it matches anyone's password in the accounts.txt file. There are programs that are easy to get and use that automate this process.

If you have a dev-type person that TRULY needs the real data from the shard, here's one possible solution: alter ALL of the account entries (via a Perl script or some other program) to have all the same old-style, plain text passwords, and remove all of the hash entries. POL -should- convert all the 'new' passwords into hashes, making them all the same thing, so your dev can test with that data, but will never know the real passwords. I've never had to do this, though, and it's best if it can be avoided.



I think you also have to look at the security perhaps not only with an eye toward purposeful harm, but accidental or ignorant harm. If you give someone direct access to the shard files, and ability to compile scripts, maybe they are perfectly trustworthy - but maybe they aren't aware of some quirk of eScript or POL itself, and maybe they implement a script without your knowledge that crashes the shard, locks it up, or corrupts some long-standing custom system you have. I have one person that does scripting, and a number of people that have altered scripts and worked on configuration issues over a long span of time. I trust all of those people entirely. However, it's not their shard; it's mine. Ultimately, I'm the one responsible for everything that gets put in. Call me a control freak (I do!), but that means I never put any file onto my production shard until I've vetted it myself.

In this, I go back to something I mentioned right at the start: time is an important factor here. The more time you see someone's scripting work (talking months and years here - not days and weeks), the more you can trust their work to meet your standards of quality. And the more time goes on where you don't see these people pulling little drama queen stunts when they don't think you are looking, stabbing others behind the back, or doing other things that should be very clear indicators that they are not to be trusted, well; the more you can trust them.

But it takes time - real time - and a willingness to understand and believe that if someone does something to someone else, they'll do it to you, as well. The fact that they say or seem to have justification for what they did to someone else just means, well... it means that everyone else will also be convinced that when they abuse your trust, they also had a good reason for it.


So.. umm... yeah

[Yukiko]

Thanks Marilla. I was counting on you to reply.
*grins*

I agree with not putting someone on who asks. I have always preferred to pull from players for staff and yes I agree that anyone who scripts, has a command level or has special access on message boards (ie. moderator etc) is a staff member.

One issue with pulling players is it can be tough when a shard is in development. If a shard is in development players are hard to come by. I suppose that's a whole new topic; How to attract players as beta testers.

I was curious about how much of your scriptset do you make available to your scripters? It stands to reason that a scripter needs to have access to some of the scripts in order to write packages and such. Since I am basically using a converted POL 095 scriptset with mods and some cleanup done by myself I had considered creating a "bare" set of scripts without any of my custom items/scripts. I'd make this available to scrupters. Thus keeping my custom shard items/scripts relatively secure.

As a side note I want to thank the POLitburo for creating this forum. We have needed a general discussion forum for a long time to address topics such as this.

[Marilla]

[Yukiko]

As I am lothe to setup an FTP server on my POL server to keep running processes at a minimum, it's an older machine and slower, I probably will stick with manual processing of script sources for now.

I appreciate the input. I like the idea of having new scripters write standalone projects. It does make it easier to test their abilities abd that way you'll get an idea of their commitment to the shard.

[Marilla]

*nods* I don't like running anything at all extra on mine, either. If you by any chance already have IIS running on any machine that is behind the firewall, you could use that. If IIS is already running a web site, adding the FTP Service really isn't much extra at all.

For my own access to my production shard, I have a firewall and VPN, and then a private FTP server behind them. Though it's on a different server on the network, I do ALL my file access (web, DB and game servers) through that single FTP service, run by IIS. I just have virtual FTP directories set up from the FTP server to the appropriate locations on the other systems, as needed. So none of the other servers need to have FTP running (one has a public FTP server for people that have fan sites we host, but that's it).

On Linux, if you are running Samba, you could do the same from another server with FTP. There are, however, some fairly lean and mean FTP servers you could get for Linux... but still.. sometimes you just really want nothing else running.. and doing it manually isn't that bad, really, anyway; It makes sure you know exactly what goes out.


Another thing that can be a pain is getting FTP through the firewall; Since FTP takes two connections, and only the control connection is on TCP/21; Active FTP is pretty much out of the question any more with widespread use of NAT Routers and incoming-software firewalls like the Windows firewall, but Passive FTP just puts the burden back on the server to have a dynamic, open port coming back in. For our public FTP server, we have a mod to our iptables stuff on the firewall server that handles dynamically opening the required data connection back in, but it has to be configured specifically for the matching control port (it comes by default set up to work with TCP/21)... depending on where your game server is hosted, TCP/21 might not be available anyway; But anywho.. umm... I'm rambling. Imagine that!

[Yukiko]

I host my game server on a Broadband connecttion ATM. I run Apache webserver running. I use an old version of PC Anywhere (PCA) for remote access to the server. The PCA ports are blocked on the router so no outside access there. I only have the necessary ports open to log in to the server and to access the webserver though for some reason now that isn't accessable. I use PCA because it allows remote operation. That way I don't need a monitor on the server. I needed the one on the server for another computer.

*laughs*

Nothing like not having the money for a monitor.

I really can't see any reason why anyone but me would need FTP access as of yet. I know if I add a trusted scripter then that will no doubt change but even then there'd be no way for him/her to restart the shard without some remote access to the computer.

[CWO]

What is the server running on? If its XP Pro, try the built in Remote Desktop. It worked very well for my shard.

[MuadDib]

If it is Windows based, set up actual accounts per individual to be able to restart shard etc, but NOT have access to the data directory, and only script areas you want them to have access to, etc etc. Works nicely. Then, as CWO said, use the built in Remote Desktop ability

[Marilla]

Something to consider for remote management - but ONLY when you have (as you do) a secure access (in my case, a VPN - in your case, you are behind the firewall anyway, so your admin traffic does not go outside of the firewall)... it's MUCH lighter on both client and server, is free, and is being actively developed;

TightVNC: http://www.tightvnc.com/
It's based on the old AT&T Labs VNC. There are other flavors of VNC available, as well, but I find TightVNC to be, well, the tightest

It's a really simple desktop; you set it up as a service on Windows (it will require WinNT/2K/XP/2K3 to do so), and set up a password for it. You then make sure the VNC service is running.

Then you can log in to it via the TightVNC client program. There's also a Java client that is automatically hosted by the server as well, to simply log in via any web browser by pointing to http://server-ip:5900/ I prefer to use the client, myself.

Note that VNC communications are NOT encrypted, so it's never safe to use to connect to a server where your connection travels an untrusted network; but when server and client are behind the same LAN (literally, or over a VPN), it's an excellent lightweight option to get full desktop access.

It does not provide file transfer capabilities, but again; it's made to be as bare-bones as possible, so that it's a small program. You can use File sharing to do the files. If you currently have file sharing disabled on that server, I actually think it would be much lighter load on the server to have File Sharing + VNC than to have PCA.


And finally, one more note: Often, you really don't need a full desktop, anyway. If your shard's running on a Server version of Windows, you can use the built-in Telnet service to provide a command shell. Depending on your network setup (same password/username on client machine, and the appropriate Windows login capabilities), you may or may not need to adjust the Telnet login settings via the Telnet Server applet (by default, it is configured only to accept integrated Windows logins, but it can also be set to allow you to type in your username/password at the standard prompt)

You would just then go to Start->Run and type telnet SERVER-IP-OR-NAME, and you'll be directed right to the command prompt of the server. From there, you can start/stop the POL service, run eCompile, and even edit text files if you get a terminal-capable text editor (the Dos 'EDIT' program that comes with Windows does NOT work properly over a Telnet session... you'll get the Edit program open, but you won't be able to use any of the menu commands!)

As with VNC, Telnet should ONLY be used over a trusted network, as it, too, sends all info unencrypted. But Telnet alone, if available, should be able to handle almost all of your server-side work for POL. The Telnet service also has a very tiny footprint memory/CPU wise.



Err... of course, if you are not running on a Server operating system, ignore everything I just said Win9X, Win2K Pro and WinXP do not have the Telnet service available. You would still use TightVNC and be 'lighter' than with PCA, though, provided you have at least Win2K.

[Yukiko]

It's WinXP system.

As for file sharing being enabled, I have to leave that disabled.

Never thought about the seperate accounts Maud. That would work. I do own an FTP server software I could setup. Then I should be able to accomplish the goal while keeping a secure environment.

[MuadDib]

I'd would recommend accounts with machine specific permissions. Goes a long way for keeping noses where they belong

[Marilla]

[MuadDib]

Aye, Windows permissions set properly, and same for the ftp server. Not just for that user's login, but for the program itself. Keep them only where they need to be.

[Yukiko]

Sorry Marilla. Yes you did recommend specific logins/privilidges for each user.

All of these suggestions are good and helpful. A lot of them assume that one has a playerbase to draw from. It is much harder when one is just starting out, or starting over, with no playerbase to choose from.

Anyway, thanks again for all the input.