0.2.8.3_beta1: Release process and bugs

[Luke-Jr]

Luke: I was hoping for more details

As far as the X crash, if I am in a menu and hit Esc however many times fast, it will take down X. If I pause at the main/last menu until the hint appears, it will exit cleanly.

You said in IRC that the input buffer thing happens when the program receives a SIGSTOP; that may be because in non-demon mode, a SIGSTOP switches stdin back to blocked mode, which freezes the server. Does anyone know how to catch signals? Ideally, we'd need to unblock stdin again when we receive a SIGCONT, right now, I just call it before every read operation, which is kind of unelegant.

man signal

I'd need more details on the wall passing. You know the drill: steps to reproduce, recordings.

Sorry, no idea. Recordings were useless last time I tried.

The X11 crash is a definite can't-reproduce for me. It does not matter whether I'm using mesa or nvidia rendering, no matter how fast I press shift-esc, the progam just exists.

Try not using Shift-Esc

Besides, you know the mantra: bluescreen type crashes are always the fault of the system, not the application. We can look for a workaround, of course, but that requires that the error is reproducible and that someone who can reproduce it has the skill required to fix it. A recording may help here, too; at least it would show the execution path the progam takes, which could give clues.

I suspect a non-clean shutdown of SDL somewhere and that Arma exits as usual.

As far as the server redirection stuff, I presume it wouldn't be backward compatible, so perhaps having it failover to a non-banning kick-with-redirect-message would be a good idea?

[Z-Man]

As far as the X crash, if I am in a menu and hit Esc however many times fast, it will take down X. If I pause at the main/last menu until the hint appears, it will exit cleanly.

Still no dice here. A recording is the only thing that could help, provided one of my systems is affected.

I'd need more details on the wall passing. You know the drill: steps to reproduce, recordings.

Sorry, no idea. Recordings were useless last time I tried.

Could you try again, please? So far, you're the only one reporting that.

As far as the server redirection stuff, I presume it wouldn't be backward compatible, so perhaps having it failover to a non-banning kick-with-redirect-message would be a good idea?

Well, there are two commands, KICK_TO with the usual kick side effects of getting you banned after a while, and that's equivalent to a regular kick for old clients, and MOVE_TO, which is a KICK without side effects for old clients. Giving the user the information to manually connect to the desired new server will not be very useful, I'm afraid, it would come in the form ip:port.

[Lucifer]

I think we're going to need to be able to ban servers from being listed in the master server.

Server a: KIDDIE PLAYLAND!!!!
MOVE_TO Server B

Server B: PEDOPHILE PLAYLAND!!!!

Let's be able to ban server a.

[Z-Man]

That's probably not a too bad idea, for other reasons (no need to play silly redirection buggers to host an evil server). For small scale list distribution, whacking a wget that fetches the ban list into the server run script should work just fine. The ban list could be a regular config file with BAN_IP lines (neatly also banning players from that IP from regular internet games) and maybe a new BAN_SERVER command that bans servers by names.

[Luke-Jr]

Won't that just encourage people to fork the master server services?

IMO, a better idea would be to make redirection optional-- have the kick message fetch the target server info and include a menu with "Connect" and "Exit".

[Z-Man]

Won't that just encourage people to fork the master server services?

What good would that be for them? They'd also have to make people use the forked master, and for that, they need to distribute their own client. And with a modified client, you can do things that are far worse to those who install it.

To make it clear, servers would only be banned if they clearly intend to harm our users. A pointless redirection cascade would not be enough for a ban (just don't go there again), but say we find out someone is using a not yet discovered and hopefully nonexistant security hole in our clients to infect PCs with a hacked server. We'd want to get rid of that server as fast as possible then.

have the kick message fetch the target server info and include a menu with "Connect" and "Exit".

Good idea, but I'll make it optional and off by default. We should be prepared for redirection abuse, but I don't think it will happen in a large scale, so on average, the annoyance of an extra menu would be larger than the annoyance of the occasional (harmless) silly redirect.

Redirections (and, in fact, the master server infrastructure itself) have another risk: imagine there is some UDP network service that is sloppily programmed so that random or foreight UDP packets sent to it crash it. Now imagine a server that pretends to be well visited and that redirects everyone who joins to such a service; the service operator would have no chance to defend against that constant attack from ever changing IP addresses.
Well, I'd say a service that crashes when random packets are sent to it does not belong on the internet.

[dlh]

@z-man: Mac OS X builds can be packaged into a dmg now.

From the command line:

Code: Select all

xcodebuild -project "MacOS/Armagetron Advanced.xcodeproj" -target "Create Full Release" -configuration Release

[Lucifer]

And of course, as previously discussed, we won't use it to ban users just because lots of people don't like them.

z-man hit it on the head, the reason we need this isn't because any of us think someone's going to abuse the server redirection, it's so that *if* someone does, we won't get blindsided by a sudden known exploit exploding in popularity. We'll have a way to deal with the situation of the moment while we study the specific issue and come up with a fix (if possible/necessary). That's all. Otherwise, it'll be anarchy as usual.

[Lucifer]

Sorry for posting twice like this, and I haven't been reading this thread closely enough to know if this stuff's already been discussed, but here goes.

Two use cases, added security for users and competitions.

Added security for users: An option when faced with a redirection to instead be redirected to the server of the user's choosing. He can note where the server operator wanted him to go, and go there, or instead go to the server he's chosen as his default redirection target.

For competitions:

Basically what we talked about for the AFL. An easy way for users to connect to different master servers from their clients. Possibly throw in an inclusion-style ban, where IPs listed are the only IPs allowed to connect. Could be a quick copy and paste and add a ! to the if statement. Server operators can just replace master.srv or addend their existing master.srv to use the one for whoever's competition. Let third parties couple it with a web app that allows users to tell the server about their IP address.

[Z-Man]

I don't see a use for a default redirection, honestly. About the alternate communities, I'll see what I can do.

Two more tasks: update the title screen and the Fedora logo. I don't even know who did the Fedora logo the first time round.

[madmax]

Any idea of including the tab completion of names for 0.2.8.3?
Since that's one of the things a lot of people use in 0.3, I guess it would be a good addition
Just a thought

[madmax]

EDIT: Ok, my connection is broken or something, my previous message got posted twice

[Z-Man]

While that is a system that works well, it is also a bit complex (with nicely separated autocompletion mechanisms.

nemostultae: Thanks, the DMG building works like a charm, after a minor adaption to the mktemp command. Odd, calling mktemp my hand that way always worked, but in the script, it failed, claiming the target did already exist. The version number in an SVN build is still empty for me, though (I don't really mind).

[wrtlprnft]

Any idea of including the tab completion of names for 0.2.8.3?
Since that's one of the things a lot of people use in 0.3, I guess it would be a good addition
Just a thought

The problem is that it relies heavily on new string functionality introduced in the trunk, and we can't really backport that because it could affect other things.

[dlh]

The version number in an SVN build is still empty for me, though (I don't really mind).

Could be from a leftover armagetronad/macosx_build_information.yml file from before the fix. It may think source kind is Release. Remove the file and rebuild to fix.