Commandline-Stats

[github-isgee]

Enhanced BaNGadm with reporting functionality ("command line stats"), to examine the progress from command line while BaNG is running. Some report information was taken from existing reports (which are already used in BaNG-web), but there is also an enhanced job status report, which shows the job queue and processing status. For this, I had to introduce the new job status "JOBSTATUS_QUEUED" (see BaNG/Config.pm), which in turn shifts previous status id's by 1. Thus, for existing "bangadm" databases, the job status information there would have to be adjusted in order to be displayed correctly in the appropriate tools. BaNG-web (even though we don't use it) has been adapted in a way it respectes the additional job status.

The PR also fixes an issue with Net::Ping which tended to work only in an inetd-based environment.

For BaNG-web, an LDAPiam module was introduced, which allows ETH-IAM authentication (this is a side product of the evaluation).

[frukto]

As first step, can you rebase this to master

[frukto]

The introduction of the job status codes is certainly a good thing. Thank you very much.

Why are you changing the values of the existing status codes? We should not depend on the actual values of these constants whatsoever . If you need an ordering on these codes, it should be done in a separate function.

[github-isgee]

As first step, can you rebase this to master

done

[github-isgee]

The introduction of the job status codes is certainly a good thing. Thank you very much.

Why are you changing the values of the existing status codes? We should not depend on the actual values of these constants whatsoever . If you need an ordering on these codes, it should be done in a separate function.

If I remember it correctly, it has to do with ordering the job status codes, which to my belief is also done in some SQL statements. So I decided it would be the cleanest solution to reorder the status codes and not add one to the end of the previous status code sequence. Actually I changed the code months ago, so I don't remember all the decisions made by then and their reasons. Of course one could write a hack for this, preserving the meaning of the existing codes, but as there were not too many dependencies on them, I thougt reordering would be more elegant.
I think the status codes are also saved in the bangstat DB, so when someone intends to continue with an existing DB, he would have to shift the existing codes there, to make the meaning of the old and new codes consistent over different record dates.