Okay, thanks!

It doesn't seem to have fixed the problem:

http://pastebin.com/giTc8Cqe

Also, there is still no log in the @aliveServer folder

We're running Ubuntu 14.04.2 LTS (GNU/Linux 3.13.0-39-generic x86_64)

arma2@1tac:~/arma3/aliveserver/@aliveServer$ ldd ALiVEPlugIn.so
        linux-gate.so.1 =>  (0xf772f000)
        libcurl.so.4 => not found
        libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf74f4000)
        libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7345000)
        /lib/ld-linux.so.2 (0xf7730000)

Try this:

sudo apt-get install curl

And then check the 'ldd' output again.

Got this when we tried that command:

sudo apt-get install curl
Reading package lists... Done
Building dependency tree
Reading state information... Done
curl is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 353 not upgraded.

ldd output is the same btw

Then this should work:

sudo apt-get install libcurl4-openssl-dev

sudo apt-get install libcurl4-openssl-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
libcurl4-openssl-dev is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 353 not upgraded.

Sorry. Seems like libcurl.so.4 is actually from libcurl3 and not libcurl4.
Try:

sudo apt-get install libcurl3:i386

That seemed to install something. :D

Still getting the same error in the RPT. http://pastebin.com/egPpWYk5

There is a new file in the @aliveServer folder called "not" (no extension) that's empty. 0 bytes.

Just did:

arma2@1tac:~/arma3/aliveserver/@aliveServer$ ldd ALiVEPlugIn.so
linux-gate.so.1 =>  (0xf7728000)
libcurl.so.4 => /usr/lib/i386-linux-gnu/libcurl.so.4 (0xf74ca000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7484000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf72d5000)
/lib/ld-linux.so.2 (0xf7729000)
libidn.so.11 => /usr/lib/i386-linux-gnu/libidn.so.11 (0xf72a2000)
librtmp.so.0 => /usr/lib/i386-linux-gnu/librtmp.so.0 (0xf7287000)
libssl.so.1.0.0 => /lib/i386-linux-gnu/libssl.so.1.0.0 (0xf722f000)
libcrypto.so.1.0.0 => /lib/i386-linux-gnu/libcrypto.so.1.0.0 (0xf7082000)
libgssapi_krb5.so.2 => /usr/lib/i386-linux-gnu/libgssapi_krb5.so.2 (0xf703c000)
liblber-2.4.so.2 => /usr/lib/i386-linux-gnu/liblber-2.4.so.2 (0xf702d000)
libldap_r-2.4.so.2 => /usr/lib/i386-linux-gnu/libldap_r-2.4.so.2 (0xf6fdb000)
libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xf6fc1000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf6fa5000)
libgnutls.so.26 => /usr/lib/i386-linux-gnu/libgnutls.so.26 (0xf6ede000)
libgcrypt.so.11 => /lib/i386-linux-gnu/libgcrypt.so.11 (0xf6e58000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf6e53000)
libkrb5.so.3 => /usr/lib/i386-linux-gnu/libkrb5.so.3 (0xf6d95000)
libk5crypto.so.3 => /usr/lib/i386-linux-gnu/libk5crypto.so.3 (0xf6d65000)
libcom_err.so.2 => /lib/i386-linux-gnu/libcom_err.so.2 (0xf6d5f000)
libkrb5support.so.0 => /usr/lib/i386-linux-gnu/libkrb5support.so.0 (0xf6d53000)
libresolv.so.2 => /lib/i386-linux-gnu/libresolv.so.2 (0xf6d3b000)
libsasl2.so.2 => /usr/lib/i386-linux-gnu/libsasl2.so.2 (0xf6d20000)
libgssapi.so.3 => /usr/lib/i386-linux-gnu/libgssapi.so.3 (0xf6ce4000)
libtasn1.so.6 => /usr/lib/i386-linux-gnu/libtasn1.so.6 (0xf6ccf000)
libp11-kit.so.0 => /usr/lib/i386-linux-gnu/libp11-kit.so.0 (0xf6c93000)
libgpg-error.so.0 => /lib/i386-linux-gnu/libgpg-error.so.0 (0xf6c8e000)
libkeyutils.so.1 => /lib/i386-linux-gnu/libkeyutils.so.1 (0xf6c8a000)
libheimntlm.so.0 => /usr/lib/i386-linux-gnu/libheimntlm.so.0 (0xf6c81000)
libkrb5.so.26 => /usr/lib/i386-linux-gnu/libkrb5.so.26 (0xf6bfa000)
libasn1.so.8 => /usr/lib/i386-linux-gnu/libasn1.so.8 (0xf6b54000)
libhcrypto.so.4 => /usr/lib/i386-linux-gnu/libhcrypto.so.4 (0xf6b1f000)
libroken.so.18 => /usr/lib/i386-linux-gnu/libroken.so.18 (0xf6b09000)
libffi.so.6 => /usr/lib/i386-linux-gnu/libffi.so.6 (0xf6b02000)
libwind.so.0 => /usr/lib/i386-linux-gnu/libwind.so.0 (0xf6ad8000)
libheimbase.so.1 => /usr/lib/i386-linux-gnu/libheimbase.so.1 (0xf6ac9000)
libhx509.so.5 => /usr/lib/i386-linux-gnu/libhx509.so.5 (0xf6a82000)
libsqlite3.so.0 => /usr/lib/i386-linux-gnu/libsqlite3.so.0 (0xf69c5000)
libcrypt.so.1 => /lib/i386-linux-gnu/libcrypt.so.1 (0xf6994000)

@aliveServer or @aliveserver ?
You should lowercase the foldername.

Your ldd output is good, so the plugin should be working now.

Edit!
Your plugin might be corrupt as well.. You should download the new plugin from the war room.
The plugin should be around 1.9MB.

Edit #2!
I just saw Friznit posted something about that earlier here. So disregard my first edit =D

It's now working! Thank's to secure, Tupolov, Friznit and SavageCDN for all your help and patience.

Another one here that had the same "THERE IS A PROBLEM WITH THE ALIVE PLUGIN!" problem and got it fixed.

I'm using 64 bit Arch Linux and the problem was that using a 32 bit software in a 64 bit environment creates a situation where the ALiVEPlugIn is "unable to find" the suitable and needed file when it doesn't exist at all OR doesn't exist in the correct file path.

So following the earlier discussion in this topic I began with checking

ldd ALiVEPlugIn.so

and got

linux-gate.so.1 (0xf7714000)
libcurl.so.4 => not found
libm.so.6 => /usr/lib32/libm.so.6 (0xf74d9000)
libc.so.6 => /usr/lib32/libc.so.6 (0xf731f000)
/usr/lib/ld-linux.so.2 (0x5664b000)

where libcurl.so.4 was not found.
The missing of this file was causing a repeated spam of "THERE IS A PROBLEM WITH THE ALIVE PLUGIN!" in the dedicated server RPT log file and @aliveserver not connecting to the War Room.

To cure this I had to install the lib32-curl package to get the sorts of cross-compatibility going for my 64 bit system.

After I did that and checking with

ldd ALiVEPlugIn.so

I was shown this

linux-gate.so.1 (0xf7739000)
libcurl.so.4 => /usr/lib32/libcurl.so.4 (0xf74c8000)
libm.so.6 => /usr/lib32/libm.so.6 (0xf747b000)
libc.so.6 => /usr/lib32/libc.so.6 (0xf72c1000)
/usr/lib/ld-linux.so.2 (0x5662b000)
libidn.so.11 => /usr/lib32/libidn.so.11 (0xf728d000)
libssh2.so.1 => /usr/lib32/libssh2.so.1 (0xf725a000)
libssl.so.1.0.0 => /usr/lib32/libssl.so.1.0.0 (0xf71dd000)
libcrypto.so.1.0.0 => /usr/lib32/libcrypto.so.1.0.0 (0xf6fc9000)
libgssapi_krb5.so.2 => /usr/lib32/libgssapi_krb5.so.2 (0xf6f76000)
libkrb5.so.3 => /usr/lib32/libkrb5.so.3 (0xf6e93000)
libk5crypto.so.3 => /usr/lib32/libk5crypto.so.3 (0xf6e5f000)
libcom_err.so.2 => /usr/lib32/libcom_err.so.2 (0xf6e5a000)
libz.so.1 => /usr/lib32/libz.so.1 (0xf6e43000)
libpthread.so.0 => /usr/lib32/libpthread.so.0 (0xf6e25000)
libdl.so.2 => /usr/lib32/libdl.so.2 (0xf6e20000)
libkrb5support.so.0 => /usr/lib32/libkrb5support.so.0 (0xf6e11000)
libkeyutils.so.1 => /usr/lib32/libkeyutils.so.1 (0xf6e0c000)
libresolv.so.2 => /usr/lib32/libresolv.so.2 (0xf6df3000)

where we can see among few new additional lines also libcurl.so.4 => /usr/lib32/libcurl.so.4 (0xf74c8000)

Bear in my mind dear reader that this fix was done with Arch Linux and might not directly apply to the Linux distro you are using. But you can still follow roughly the same principle.

Also about another thing:

I was skeptical that like secure asked from Feanix

@secure
@aliveServer or @aliveserver ?
You should lowercase the foldername.

case-sensitivity would play any role if you got it right on the -mod=@mod1 -line but apparently it did. The thing is even more funny that I could get away with using @AliveServer as the folder name (and in the -mod= -line) before fixing the main problem I was talking about earlier in this reply. But since I got that problem fixed I couldn't anymore use @AliveServer (as the folder name nor in the -mod= -line) because the server would crash during loading the game map always with the same "error message":

Segmentation fault (core dumped)

and nothing else. That is a Arch Linux message printed in the console right after the server crashed. There is nothing to be seen in the server RPT log, it just abruptly ends.

So, if ALiVE devs know about this case-sensitivity maybe they could distribute the @aliveserver -folder written in lowercase?

What is this aliveserver.so file? Do i need it? My dedi server wont accept it when i try to install it?
Thanks