conz 1 Posted January 23, 2013 I'm busy (for the first time) trying to set up an Arma2 OA server on Linux (Centos 6.3 64bit) I've been doing some digging and from what I can tell running the server is pretty straight forward but securing it is a whole different ball game .. We're planning to run DayZ and (probably) a normal Arma2 OA server. -For starters I already copied the latest battle eye server file for Linux. -I saw the post of putting config files outside the server directory, so that's on the list. (from the 'how to secure your server' post) What else can be done to keep the amount of problems to a minimum ? To my surprise I was unable to find a howto of sorts on best practices. As a small side question, DayZ *has* to run in Wine ? Share this post Link to post Share on other sites
Stuffy 1 Posted January 24, 2013 Securing DayZ-Servers is a whole different story since its PvP and not PvE, which normal arma2 oa mostly is. I guess there are plenty of tutorials out there which describe how to set-up battleEye to keep the users from executing scripts on your dayz-server. For nomal Arma2 OA battleEye is enought in my opinion, since it's keeps away most of the hacks. And since its mostly PvE, it's no fun for the hackers to use aimbot or wallhack, since it's just bots they are shooting at. As a small side question, DayZ *has* to run in Wine ? I think yes, because the plugin that is needed to connect with the master-server-database only works on windows. Share this post Link to post Share on other sites
conz 1 Posted January 25, 2013 Securing DayZ-Servers is a whole different story since its PvP and not PvE, which normal arma2 oa mostly is. I guess there are plenty of tutorials out there which describe how to set-up battleEye to keep the users from executing scripts on your dayz-server.For nomal Arma2 OA battleEye is enought in my opinion, since it's keeps away most of the hacks. And since its mostly PvE, it's no fun for the hackers to use aimbot or wallhack, since it's just bots they are shooting at. I think yes, because the plugin that is needed to connect with the master-server-database only works on windows. I just ran into the 'GLIBCXX_3.4.15' problem which threw a giant brick into running arma on this server.. Can't upgrade the libs on Centos 6.3 or its guaranteed to break. I saw something about BI's linux compiling machine breaking but they might have gone a bit too bleeding edge with their new one in my opinion. Share this post Link to post Share on other sites
Overlord 0 Posted January 25, 2013 Search forum for GLIBCXX + centos, and you'll find you got yourself a nice little weekend challenge here :) But as several says, it's possible to solve. An easier solution for you (if possible) would be running another distro (e.g. Debian/Ubuntu). Happy compiling ;) Share this post Link to post Share on other sites
conz 1 Posted January 29, 2013 Search forum for GLIBCXX + centos, and you'll find you got yourself a nice little weekend challenge here :) But as several says, it's possible to solve. An easier solution for you (if possible) would be running another distro (e.g. Debian/Ubuntu).Happy compiling ;) If it was *just* running Arma I'd consider that for sure :-) I'm going to see if I can somehow get this to work properly, too many fixes in the newer versions to ignore. Share this post Link to post Share on other sites
conz 1 Posted January 30, 2013 Just as an update for future reference. Turns out you do NOT have to update GLIBC (which would break the whole server) Instead you can just get gcc ( http://gcc.gnu.org/ ) and here is what I did: (This is CentOS 6.3 x86_64 fully patched to jan 30 2013.) #Install required packages, including 32bit devel packages for glibc.yum install gmp mpfr mpfr-devel gmp-devel libmpc libmpc-devel glibc-devel.i686 #Some parameters I picked up from random gcc compiling post. No idea if needed. ./configure --enable-shared --enable-threads=posix #Compile with 4 threads, gcc takes LONG to compile! Rule of thumb is number of cores + 1 but I was playing nice to other processes. make -j4 #copy the freshly compiled SO file to /usr/lib, I did NOT 'make install' to prevent possible mess ups, afaik only the .so is enough! VERSION NUMBERS MIGHT ALSO DIFFER! cp /root/gcc-4.7.2/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/libstdc++.so.6.0.17 /usr/lib cd /usr/lib #Remove old symbolic link rm -f libstdc++.so.6 #Link new file to libstdc++.so.6 ln -s libstdc++.so.6.0.17 libstdc++.so.6 How to get back to defaults: cd /usr/lib rm -f libstdc++.so.6 ln -s libstdc++.so.6.0.13 libstdc++.so.6 (check version number to be sure: ls -al libstdc++* ) You can also put the .so in the server dir but I could not get the variable to work and did not bother to dig into it too long. Share this post Link to post Share on other sites
Jim 1 Posted January 31, 2013 It's funny because I'm working on setting this up now but it's a massive hardship. I looked through a lot of tutorials and never could figure it out and am still presently working on it. As far as the error you got, I believe you fixed it with moving the .so.6 file over to the other directory (don't remember the specifics). Something I also ran into was making sure all my directories were in lowercase and not uppercase, that can kill the server if you don't do that by making your arma 2 server life a living hell. All the insight I can offer for now and if you wouldn't mind I'd really like to know how you did it because I'm not currently able to figure it out at all, despite how many tutorials I watch on it. Share this post Link to post Share on other sites
conz 1 Posted February 4, 2013 if you wouldn't mind I'd really like to know how you did it because I'm not currently able to figure it out at all, despite how many tutorials I watch on it. Which bit ? I compiled GCC (not GLIBC like so many posts say!), copied the new so over and swapped the symlink, that was enough to get the server to start. It ran for a few days before I killed it, not with people on it yet though. Share this post Link to post Share on other sites