redshirt_ensign

Yeah, your server is failing to start. Something is wrong with your files, folders or configs. We can sort it out from here via PM.

OK, well you do have some rules but the default policy is ACCEPT so yeah iptables are fine. You are on a single public IP too so thats fine too. Must be the (arma) server itself. You do have a an RPT with the linux server but it piped to STDOUT and then the startup script redirects it to a log file. By default it is named after the port you are using - eg: "log.2302.txt" - but in your script you are naming it "serverlog.txt". Do you have that log file?

Sorry mate I was away from home for a few days there. You may not have setup iptables but it would be better to see an output from "iptables -L -vn" to check if there are any pre-configured rules in place that you are not aware of. You did not answer my question about the IP address(es) of the server. Is it a private or public IP? Are there multiple IPs? (output of "ifconfig" would show this) Are you sure the server is starting properly? Can we see some of the RPT log (serverlog.txt)?

Define "all the ports are open" ... Where is the server? A dedicated? VPS? Home network? Is it on a private IP (10.* 192.* etc) and behind a NAT device? If so have you forwarded _all_ the required ports? Any reason why you are using 2305 and not the default of 2302? When you say "remote" you are talking about putting the IP directing into "Remote" search of in-game multiplayer browser? (which should work regardless of Gamespy working) On linux what is you IPTABLES setup? (run "iptables -L -vn")

Check the RPT file (on linux is just console output piped to a log, probably called "log.2302.txt" unless you have changed defaults) for what PBOs it is not finding when you connect. Post snippets here if you want me to check it over. Post your "arma2oaserver" script. You have edited it to set paths right? Problem could be path to beta, I always had to include param for it on my linux server (using the OTHERPARAMS var). This was mine: OTHERPARAMS="-beta=expansion/beta;expansion/beta/expansion -profiles=wasteland -name=wasteland -cfg=./wasteland/basic.cfg -cpucount=2 -maxMem=2047" NOTE: you will need to remove the -profiles -name and -cfg params or change them to suit you current "player" profile dir name.

All that stuff is just ENV vars that are being set into the shell that the script is running in. Some of them then get used as command line parameters in the actual bit of the script that runs the server binary: ${SERVER} >>${LOGFILE} 2>&1 -server -config=${CONFIG} -port=${PORT} -pid=${PIDFILE} As you can see, only SERVER (the binary), LOGFILE, CONFIG, PORT and PIDFILE are being used. Just setting ENV vars isn't enough for the server to know about them, you need to actually submit them as params to the "server" binary. Where did you get that start script anyway? Both the current 1.63 Linux and even the previous 1.62 Linux bundle uses a start script that has an ENV called OTHERPARAMS (which is included in the command line call to server) and by default it includes the "-cpucount=2" param already: #======================================================================= #======== CONFIGURATION PARAMETERS ======== #======== MUST BE EDITED MANUALLY TO FIT YOUR SYSTEM PARAMETERS ======== #======================================================================= ARMA_DIR= CONFIG= PORT=2302 PIDFILE=${ARMA_DIR}/${PORT}.pid RUNFILE=${ARMA_DIR}/${PORT}.run LOGFILE=${ARMA_DIR}/log.${PORT}.txt SERVER=${ARMA_DIR}/server OTHERPARAMS=-cpucount=2 #======================================================================= and ${SERVER} >>${LOGFILE} 2>&1 -server -config=${CONFIG} -port=${PORT} -pid=${PIDFILE} [b]${OTHERPARAMS}[/b] Although for yours (based on the params you seem to want) I would make that OTHERPARAMS="-cpucount=2 -maxMem=2047 -nologs" Lastly, as Savage already pointed out, you will only ever get the 2nd core to be used for AI threads, so don't be alarmed if you first start the server and still only see 1 core getting constantly thrashed at 100%, the 2nd core will start fluctuating up to more and more usage as the need for AI processing occurs. This is why the optimal server for Arma 2 is to have a very high clocked dual core (or quad since that leaves some cores to run mysql and/or the rest of the OS) running on dedicated hardware with no hyperthreading or any other potential drain on pure uninterrupted access to that 1 single core that is doing almost all the work. Hope this helps :)

Wow thanks for posting that. Very curious little bundle. He seems to have kludged the DB i/o layer that would normally use Arma.NET SQL calls for hive interaction, and replaced it with a system of output (DB writes/queries) via console log (using debug messaging I assume) and inputs (DB reads) by building temp sqf scripts and running them. I once contemplated doing something similar for basic db support in Wasteland ... but this very complex by comparison. He has even got an "epoch" binary running it all (I assume it is just a wrapper to the linux dedi binary). My only concern is whether there is any hive lag due to all that console log scanning and sqf file creation/loading. Still very clever none the less. I recently went the other way and just started running the win dedi via WINE instead (talking to local linux mysql server but using the DLL for sql support).

How do you plan to run the hive db (DayZ) stuff anyay when Linux Dedi has no CallExtension (DLL) support?

FWIW I have just managed to get an MSO 4.5 server up and running on Ubuntu 12.04 64bit (Win dedi running via WINE) with PDB running off native (linux) mysql server. Mostly I just followed HOWTOs for doing the winetricks installs required for DayZ server (dotnet4, dx9, etc) and then copied into place a fully working Arma2 OA / MSO folder from a Windows server. Could not get the dotnet mysql connector to install via WINE but didn't have to since we had already placed the DLL in the server root on the windows server when we had PDB issues there. MySQL was pretty simple since you just need basic linux mysql-server install then create the user and grant it all privs. One thing that held me up for a few days was that all of the WINE stuff (especially the winetricks and creating the wineprefix to run it all under) needs to be done in 32bit mode (WINEARCH=win32). Otherwise you won't get dotnet4 to install and a bunch of other things fail too. If your server is remote (headless) then you will first need to go through what I did to get a VNC-based Xorg windows session that runs from the main server console (using a dummy display module and pre-baked xf86config). Most VNC and/or xRDP services will create new X sessions on connection (and then kill them on disconnect), and this will be no good for running a dedi server. I know this isn't a very good write-up (sorry) but I am trying to recall it off the top of my head and it took me about 2 weeks, 10 installs of Ubuntu, 3 different Window Managers, 4 different xRDP/VNC installs and unknown WINE setups to get it right myself :P Let me know your setup and I can start to try and tailor the advice accordingly.

Should be plenty. I had the number #2 ranked Arma (Wasteland) server in Australia for 2-3 months there - so it was full 60/60 for large chunks of the day and never empty - and even that on ran up about 350-400GB outbound (maybe another 150-200GB inbound).

Forget about 70. Even decent dedicated servers struggle to do that without desync (especially Wasteland). You might do 50 but only if the cpu quality of your vps is good enough. You preferably need 2 cores with decent clock speed and pray that the xen host your vps is on isn't over worked.

What? They are finally putting callExtension support in the linux binary? When/where was that announced??? EDIT: Oh, did I miss the sarcasm in that? lol, trolled me good :p

You can't. None of us can. That's the problem. The main server / script engine will run one core at 100% the whole time and AFAIK only some of the AI processing will be threaded off onto a 2nd core which will then fluctuate in % util. Cores 3 and 4 will do nothing (or you can run a 2nd server off them). Arma 2 is all about pure single core performance. So if you have the option to disable hyperthreading on that E3 go for it.

Yep, that script is completely default. You will be running on 2302 (but we already pretty much knew that). You have to understand, Arma2 doesn't have RCON natively. It is BattlEye that provides an RCON interface to the server. So (with the exception of manually defining a new -bepath param) there is nothing in the startup script that will affect you getting RCON access. You need to concentrate on BattlEye. With the linux install (assuming you have done it all correctly), your linux BattlEye lib "beserver.so" should be at [ARMA2DIR]/expansion/battleye/beserver.so and you should make the cfg file at [ARMA2DIR]/expansion/battleye/beserver.cfg along with [ARMA2DIR]/expansion/battleye/bans.txt [ARMA2DIR]/expansion/battleye/scripts.txt [ARMA2DIR]/expansion/battleye/remoteexec.txt etc etc and Yes, every single file (including mission PBOs) should be in lowercase for linux. Like I said, you will know if you have got the cfg file successfully found if it gets renamed to "beserver_active_abc1234.cfg" after you start the server (where abc1234 is some random value). If the cfg file doesn't get renamed, don't even bother trying to connect an RCON client as it won't be listening for it.

"arma2server" is the start script. run command "less arma2server" to view contents (press Q to exit when done). If you haven't edited it, it is doubtful that your port is non standard. Are you sure you are putting the beserver.cfg in the right directory? EDIT: What did you "port check" with anyway? You know it is UDP port 2302 right? If people are playing arma on port 2302 then that is the port BE will be using (but it won't run at all if it doesn't find the cfg file where it expects it to be). You will know if your beserver.cfg file has actually been found by BE if the filename gets changed to beserver-RANDOM.cfg ("RANDOM" will just be some random chars)

Ubuntu will be the easiest due to the gcc libs required. There is details setup instructions on wiki. Before you put in all the work though, are you sure you can run a Life server under Linux? You know there is no CallExtension support for Linux right? Like, no external (hive) db support. Doesn't Life have all kind of db related stuff in it?

No worries man, I just swapped them (engineers) out for jungle camo US/RUS units from Arma2. The new version of the map is great!

lol, apparently your server specs are famous Skutch ;) Yeah, look I am in a similar boat, in that we have a very busy Wasteland server on what is rather high end bandwidth and looking to optimise as much as possible (in my case I can't boast the same CPU/RAM benchmarks because ours is a VPS on Amazon, but the bandwidth/connectivity is still about as good as it gets here in Australia). Just from what I have managed to to decipher in all of these threads (about basic.cfg voodoo), it seems that the most pertinent details besides bandwidth are actually the number of slots you are running and what kind of client msgs quantity you have ... and with wasteland both of those are quite high. We mostly run 60-70 slots (full) and the wasteland code is littered with publicvariables and other non-stop broadcast noise to/from all clients. Anyway, I thought I should mention this since so many of the posts about super awesome basic.cfg setups always seem to be for some 30 slot domination or standard mission server. Can anyone suggest good settings for 60-70 slots with high msg traffic (assuming bandwidth wasn't an issue)?

Ah, thanks Rudy. I wondered if I should just ask you directly since it is actually a Wasteland port I am doing (sorry I didn't even know about yours until a few weeks in to dev with ours, so not a copycat I swear ;) ) Oh well, glad to know it wasn't something I was doing wrong with the mission.sqm (eg. missing an addon ref). Hey, speaking of lingor_units addons in the mission.sqm, how did you work out all the required addon entries for non-vehicle items such as the guns? As you know, with Wasteland the guns get put in via sqf code (inserting them into cars and weapon crates) so not something that you can simulate with the mission editor ... or can you? (I tend to do everything through text editing so rarely use the mission editor)

Hey guys, I am currently in the middle of setting up a mission with lingor/lingor_units and for some reason the Engineer/Saboteur classes are not able to repair disabled vehicles like their non-lingor equivalents. The lingor medics are working correctly but not the Engineers. Has this already been discussed / covered here? Or am I messing something up with the mission? Cheers

Lead admin/dev of Face First Wasteland here. You should head on over to the 404 Wasteland Forum. There will be plenty of threads you can read and then create new ones to ask questions as you learn more.

Awesome, loving the new BanReasons config class. Don't suppose there is such a class name for Kicking too? These are great for getting my admins to be more consistent with ban/kick messages they use. :D

What? :eek: Oh crap, lack of emoticons fail on my part. Sorry man I really wasn't being sarcastic but I can totally see how it came out like that. No, I only asked because the v1.1 download currently limits access to the player DB just like the v1.0 Basic did. I am more than happy to go do another FB like (or whatever), I was just asking if that was the reason. I use your v1.0 premium daily (along with my other 2 admins) and do utilise the DB tab quite a bit (dealing with players that have already left before getting banned). Anyway, thanks for the new version and sorry for the misunderstanding.

Great news Soner! Just curious, do existing Premium users have to go and do another FB Like to get a version with player DB again?

Indeed. Perhaps he meant to have EXP="expansion/beta;expansion/beta/expansion" in there for the beta folders (although that would be better put into a "-beta=" param anyway).