B3 0 release

[k3ldar]

CORE-782

Does not include an error or status code as this would change the parameters of gds__log

[AlexPeshkoff]

Sorry, I think this PR can't be accepted.
For logging attaches audit should be used, i.e. we have duplicated feature.
Removing \n between messages of a log makes it worse human-readable
May be use of per-day log files in separate directory can make sense, not sure....

[romansimakov]

2017-01-23 13:57 GMT+03:00 Alexander Peshkov <notifications@github.com>:

Sorry, I think this PR can't be accepted. For logging attaches audit should be used, i.e. we have duplicated feature. Removing \n between messages of a log makes it worse human-readable

I guess it may be optional. Our admins manu times ask to change a lof format to be more machine readable. I.e. one line per one event. Also log level is very useful. Maybe even split output depends on message level to separate warnings and errors. It makes monitoring server halth more easy.

…

May be use of per-day log files in separate directory can make sense, not sure....

-- Roman Simakov

[AlexPeshkoff]

Roman, I see no problems if such changes (removing extra \n) are optional. If k3ldar is ready to make appropriate changes I'll be glad to accept such PR.

What about logging levels - that's definitely very useful, but IMO requires some good thinking how do we implement it (numeric levels or groups? what levels/groups? what message to put where? etc.)

[dyemanov]

I'd say this requires discussion in fb-devel. We already had an idea to have logging plugins to switch from default format to something else. In this case, logs location and rotation policy may be options of the plugin, not the server. We already have requests to separate engine errors from remote errors, as well as write validation results into dedicated files. Severity levels should also be discussed in this context.

[dyemanov]

@AlexPeshkoff:

For logging attaches audit should be used, i.e. we have duplicated feature.

Doesn't audit work at the engine level, while authentication now works at the server level?

[AlexPeshkoff]

On 01/23/17 15:23, Dmitry Yemanov wrote: @AlexPeshkoff: > For logging attaches audit should be used, i.e. we have duplicated feature. Doesn't audit work at the engine level, while authentication now works at the server level?

Point. Agreed, failed authentication will not be audited now. But must I'd better think about fixing trace&audit - nothing prevents to call trace plugin from network server code.

[k3ldar]

Would happily make changes required for the interim, but the idea of a plugin for logging could be even better long term (appreciate this may take longer for you guys to implement). I did put in a basic "LogLevel" for logging failed/success audit entries, as appreciate many would not want that level of data, I could happily change the PR to have as is as default, then different log levels for changes. I am happy to go with whatever you guys decide, but would appreciate the extra logging so as I can better protect my servers in the meantime :-) Si On 23 January 2017 at 12:31, Alexander Peshkov <notifications@github.com> wrote:

…

On 01/23/17 15:23, Dmitry Yemanov wrote: > @AlexPeshkoff: >> For logging attaches audit should be used, i.e. we have duplicated feature. > Doesn't audit work at the engine level, while authentication now works at the server level? > Point. Agreed, failed authentication will not be audited now. But must I'd better think about fixing trace&audit - nothing prevents to call trace plugin from network server code. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#76 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFVD7Wz3e0T7M6ZzQi0U_VSL__QWvuz-ks5rVJ2HgaJpZM4LqUWs> .

[k3ldar]

Could you please close/delete this pull request, as submitted a revised version under the header of CORE 782.

Thanks

Si