20% Cooler
  • Content count

  • Joined

  • Last visited

Community Reputation

5 Neutral


About Zazabar

  • Rank
  • Birthday 09/19/86

Profile Information

  • Gender
  • Location
    VA, USA
  • Favorite Pony
    Queen Chrysalis
  1. Did someone call me? No? I come anyway.
  2. I honestly don't even agree with it 100%. If you are solo queueing, most people in lower MMRs can't even take proper advantage of a hard support. I've gone around warding all game, pinging when people were coming, and the carry would just stay there and keep farming and get ganked. Playing a position 5 support in solo queue is no fun. Now playing with other friends? I don't have a problem following those rules.
  3. ^ The above post of course assumes you are playing position 5 hard support. Position 4 support is slightly different.
  4. I don't see how spectators could be a bad thing. Might help the issue of friendlies. Then again, maybe not. Some people friendly because they want to play as a pony but not participate in the normal rounds. Nothing you can do to stop that other than ban.
  5. That is quite surprising! I've seen you on DOTA Kibbles but I haven't seen you play with guildies yet :O
  6. Kibbles and bits? :D
  7. And then Calzone scored 20 kills and lifted the entire team on his back through the enemy fountain.
  8. Also, Calzone is a good teacher, so if you feel like you don't want to join cause you are bad, don't let that stop you. You'll learn a lot from playing with us.
  9. And on a final note. Run a domain whois on You will find that they are being hosted by dreamhost. All of dreamhost's hosting options include the ability to add multiple databases and database users. So there is no reason why this can not be done here.
  10. I would figure that since Raini is running forums, that she has more than one server in which she is hosting, since she is probably hosting the databases on here and not on the gameserver. If you are gonna run a full game server/forum/donate setup, you really should have a basic webserver that can run these very basic things. Edit: I would also like to add that I get the above setup for $7/mo. So if I can get it, anyone can.
  11. No, I am not new. You can easily do the following: Database 1: Forums Database 2: Donator Info Database 3: Server Shit User 1 : Has read/wire to forums, read to donator User 2: Has read/write to server, read to donator User 1: used in config.php User 2: used in database.cfg Bam, if someone steals the database.cfg stuff, they can not modify the forum.
  12. Second post, showing proof for my previous statements.
  13. Because that is the way the people behind TF2 and Sourcemod designed it. But to verify, information about forum users passwords and such are not in that file, right? No, passwords for forum users are not kept within that file, but in a separate database off the game server. It would have been possible however to do a lot of malicious things to this forum using the database passwords contained within the game server's databases.cfg. Upon discovering that Dinky had shared FTP access, I checked the connection logs for all of these databases, and I did not discover any evidence of IPs that I did not recognize connecting to them. The point remains however that the access should have never been shared with an outside party in the first place; especially not an ex-Admin who was removed due to abuse. Donors will continue to have all of their perks on all of our servers: Ponyville California (, Ponyville VSP #1 (, and Ponyville VSP #2 ( If you are not seeing your Donor perks on one of these servers right now, it is because I am still in the process of reinstalling the server and/or transferring files. All existing Donors will be credited for every day that they are not receiving their perks on the servers. A security suggestion if you are willing to listen. Each instance of database access should have it's own username and permissions. So for instance, if the database.cfg contains a database user/password to access the database for say, a tf2 table, it should not have permissions to access data from other tables. If you give each access point it's own user/permissions, you reduce risk dramatically. No script should have a user account that can globally access the databases. That way, even if someone were to say, steal the info from database.cfg, they wouldn't be able to do anything to the forums. Edit: Also, you should limit the IPs that can connect to the database to only include localhost, the ips for the servers themselves that need to access it, and that is it. Any database updating can be done through cpanel or whatever site suite you use. No one should need remote access to the database. It's pretty commonplace for php scripts and stuff like sourcemod to store database passwords in plaintext unfortunately. It's also pretty common for gameservers to host MySQL remotely, as these machines do not have the resoruces to run it (since they have tons of dedicated server processes on them). With properly configured hosts, you can set the SQL server to only accept outside connections from specific hosts, but many hosting companies do not allow much configuration to SQL aside from configuration of your own databases/tables (which it creates all under your single login/account). That being said, limiting to localhost is not an option, and using a different password for each DB is not an option, nor is using different passwords for each DB (since each db just gets a different prefix but uses your same account/pw). The passwords of users and such for forums would be stored in md5 hashes inside of the database though, so there's that. Could always segregate the donor/forum db but it most likely already is. probably not a big deal. Same kinda thing goes for webservers, that stuff will all be plaintext too. Why is using separate passwords for different databases not an option? I do it on every single server I run. Even the most basic hosting services allow for adding database users and adjusting permissions to different databases. And I'm quite aware of how many config files store things in plaintext. I'm sure the passwords for the forum itself here are stored in plaintext for it's config.php file.