Opaque EULA Failure

[marcuswhybrow]

Vanilla minecraft servers now will not start unless eula=true is found in server.properties. MSM isn't aware of this process and only obfuscates this issue.

Possible solutions:

1. Automatically force eula=true in server.properties (bad form)
2. Code for this case and notify the user to read the eula and edit server.properties (inellegant)
3. Always output server logging when a new server is started for the first time, deobfuscating the issue.

Solution three seems like the best option to me.

[klp2]

Assuming number 3 ends up as the solution, it probably doesnt matter much, but 't looks like the problem description isn't completely accurate. As far as I can tell, setting 'eula=true' in 'server.properties' does not work. Instead a 'eula.txt' file must exist with this line.

[marcuswhybrow]

Ah yes you're right. Haven't tested it but the literature seems to suggest there is a line in eula.txt that needs to be set to eula=true.

[Fr33maan]

msm should prevent user at first start that he/she must accepts eula and then automatically create a eula.txt no ?

[stooj]

Yes, Minecraft server creates a file called eula.txt containing eula=false on first run, then stops execution with a message prompting the user to update the file.
Changing false to true alllows the server to be run normally.

[kjkazinski]

Wouldn't it be possible to check for the file and a regular expression to check for eula=true?

[jrbooth3]

for FILE in $(find . -name eula.txt -type f); do cat $FILE | sed
's/FALSE/TRUE/g' > tmp.txt; mv tmp.txt $FILE; done

On Fri, Jul 10, 2015 at 7:22 PM, kjkazinski [email protected]
wrote:

Wouldn't it be possible to check for the file and a regular expression to
check for eula=true?

—
Reply to this email directly or view it on GitHub
#271 (comment).

[renderorange]

Assuming there is a stipulation in the Eula where the user needs to manually accept it by changing it to true, I don't want to assume the script changing it to true will bind lawfully in the same way. It would be worth investigating.

[kjkazinski]

Blaine,
I think we are thinking different things.  Have MSM report the error so when MSM starts up a minecraft server it checks and reports the Eula has not been accepted.
  From: Blaine Motsinger [email protected]
To: msmhq/msm [email protected]
Cc: kjkazinski [email protected]
Sent: Friday, July 10, 2015 9:37 PM
Subject: Re: [msm] Opaque EULA Failure (#271)

Assuming there is a stipulation in the Eula where the user needs to manually accept it by changing it to true, I don't want to assume the script changing it to true will bind lawfully in the same way. It would be worth investigating.—
Reply to this email directly or view it on GitHub.

[renderorange]

@kjkazinski thanks for the explanation.
I was specifically speaking to the for loop @jrbooth3 mentioned, which would update the eula.txt file, which as @marcuswhybrow mentioned earlier in this issue, would be "bad form."
I'm working to set up a test server and will update on my progress with this request as soon as I have anything more to offer.

[jrbooth3]

I think the eula.txt is part of the first start so that first start would
always fail. A plan could be look for the file if its not there start and
stop server which creates the file and then alert the console that the file
needs to be read and agreed to.

On Sun, Jul 12, 2015, 2:04 PM Blaine Motsinger [email protected]
wrote:

@kjkazinski https://github.com/kjkazinski thanks for the explanation.
I was specifically speaking to the for loop @jrbooth3
https://github.com/jrbooth3 mentioned, which would update the eula.txt
file, which as @marcuswhybrow https://github.com/marcuswhybrow
mentioned earlier in this issue, would be "bad form."
I'm working to set up a test server and will update on my progress with
this request as soon as I have anything more to offer.

—
Reply to this email directly or view it on GitHub
#271 (comment).

[renderorange]

One of the immediate issues I found in testing yesterday was that MSM defaults to installing an old version of Minecraft Server, which isn't subject to the EULA issue. So, because multiple versions can be run, I'm thinking something like:
if version > x (the version which the EULA txt file started), check for file and EULA line, warn and exit.
This would maintain the ability of multiple versions of Minecraft Server to be present and able to be run, which is one of the strengths of MSM, in my opinion.

[renderorange]

On a local dev branch, I've added a check for EULA=true in the server_start() function, which will notify the admin if the eula has not been accepted. The minecraft jar will not start, per it's own requirement for the eula, but the admin will not be unaware anymore.

Given all Vanilla and CraftBukkit jars since 1.7.10 require eula.txt set to true to start, I don't believe this addition should cause backwards compatibility issues, unless there are a fair amount of users which are running jar versions older than 1.7.10, which I am unsure of. This could be a wrong assumption on my part, though.

Currently, CraftBukkit downloads are down, due to a DMCA takedown request. Depending on the direction that issue ends up going, the inclusion of CraftBukkit could be addressed seperately. However, currently running CraftBukkit servers should all still be subject to the eula check. If someone has the jar available, they could ultimately still use it for first run on server creation, just not downloaded from the CraftBukkit servers.

The check will happen for each active world server startup. Adding it to the server_start() function will also allow for the other server start methods to utilize this check, whether "msm [start|restart]" or "msm server [start|restart]".

Adding it to check during each startup, IMO, was the least complicated addition to the script. As well, if the eula.txt is removed or changed, even after first startup, the jar will give the same eula error again, which means msm should check on each startup.

If there are a number of users using jars older than 1.7.10, please feel free to chime in. If there are no objections to this, I'll push this up this evening.

[marcuswhybrow]

How about this: If eula.txt is present require EULA=true to be within. If eula.txt is absent carry on.

This would alert the user to a "EULA blocked" start. This assumes eula.txt is recreated if deleted (according to http://gaming.stackexchange.com/a/199003/6346)

[renderorange]

the way I have it structured, the eula check happens after the server has been initiated to start, which means the jar will recreate the eula.txt before the check will ever happen.
Do you mean to check for the existence of the eula.txt to ensure admins running < 1.7.10 won't be affected?

[marcuswhybrow]

Exactly. So if it's a EULA version we end up enforcing it. If it's not (<1.7.10 as you say) we don't.

[renderorange]

Just testing this quickly, there isn't any logic in msm to alert the admin if the EULA failure message happens.
This can be seen by removing my code block and simply removing the eula.txt file. On startup, the jar warns of the EULA, then exits, no warning to the admin

# rm -f eula.txt
# msm testing start
(...)
Starting server... Done.
# cat latest.log 
[23:21:18] [Server thread/INFO]: Starting minecraft server version 1.8.7
[23:21:18] [Server thread/INFO]: Loading properties
[23:21:18] [Server thread/WARN]: Failed to load eula.txt
[23:21:18] [Server thread/INFO]: You need to agree to the EULA in order to run the server. Go to eula.txt for more info.
[23:21:18] [Server thread/INFO]: Stopping server

[renderorange]

and just to clarify, 1.8.7 does recreate the eula each time if it's missing.

[marcuswhybrow]

Yer. We could either detect the error message (means listening for all incarnations) and propagate upwards. Or we can predict the error: as would be the case by checking the EULA ourselves.

[renderorange]

The order of the check could easily go like this without much change to my addition:
msm start
server jar is invoked
(server jar will create eula if missing)
msm checks jar version
if > 1.7.0
display error if eula.txt not true
else
do nothing

This seems to be in line with what you're suggestion? It would allow for older versions, as well as error as desired for newer

[marcuswhybrow]

Wouldn't using version numbers to decide add complexity? Wouldn't the fundamental way to decide be to check for the eula.txt file existing?

Is there a benefit to basing that decision on version number? There's nothing to say all future versions will require EULAs.

[renderorange]

Actually, that would make more sense to just check for existence, since the jar will create the file if it's a version that requires it. I assume that's what you were saying with your original comment? Haha, complicated indeed.

[marcuswhybrow]

Yes, sorry I garbled it.

[renderorange]

nah, I meant me, complicated

[renderorange]

tested and verified with
minecraft server version 1.5.2
starts without checking eula
minecraft server version 1.8.7
warns if eula is not set to true

[renderorange]

closing this one out. If there are any issues, please reopen.