RFE support of Session Tracking Control internet draft

[tbordaz]

Is your feature request related to a problem? Please describe.
It is helpful for ldapclient to get a tracking identifier logged, in the LDAP server logs, along with operations. The internet draft propose an implementation

Describe the solution you'd like
Implement a limited version of that draft focus on logging the session tracking identifier

Describe alternatives you've considered
Logging all information proposed in the draft is overkill and would impact the readingness of the logs

Additional context
replication will take benefit of this RFE to help diagnostic
see https://www.port389.org/docs/389ds/design/session-identifier-in-logs.html

[mreynolds389]

I have some concerns about this logging line:

SESSION "15.0.180.201 hostname=my_laptop.example.com 1.3.6.1.4.1.21008.108.63.1.2=STID_MULTI_54321"

First I don't think it should be one quoted string. I think it might be better to do:

SESSION ip="15.0.180.201" hostname="my_laptop.example.com" oid="1.3.6.1.4.1.21008.108.63.1.2" sid="STID_MULTI_54321"

Also does the oid have anything to do with the sid? The original logging line it makes them appear connected, but are they?

[tbordaz]

I have some concerns about this logging line:

SESSION "15.0.180.201 hostname=my_laptop.example.com 1.3.6.1.4.1.21008.108.63.1.2=STID_MULTI_54321"

First I don't think it should be one quoted string. I think it might be better to do:

SESSION ip="15.0.180.201" hostname="my_laptop.example.com" oid="1.3.6.1.4.1.21008.108.63.1.2" sid="STID_MULTI_54321"

Also does the oid have anything to do with the sid? The original logging line it makes them appear connected, but are they?

Note that the chosen option is the 3rd that looks like

[17/Oct/2024:17:21:51.930944766 +0200] conn=2 op=7 SRCH base="dc=example,dc=com" scope=2 filter="(objectClass=*)" attrs="distinguishedName"
[17/Oct/2024:17:21:51.931113128 +0200] conn=2 op=7 RESULT err=0 tag=101 nentries=1 wtime=0.000189515 optime=0.000171470 etime=0.000358345 notes=U,P details="Partially Unindexed Filter,Paged Search" pr_idx=0 pr_cookie=-1 sid="STID_12345"

The current implementation is limited regarding the draft. From the control it ignores ip address, hostname and formatOID. It just logs the 15th first chars of the sessionTrackingIdentfier (sid=xxx).

[progier389]

I agree with Mark about the quote.
about the oid and the sid, if I understand rightly the internet draft, the oid is the format syntax of the sid so they are related but not connected
But anyway as we plan to go to option 3 (i.e: only the sid is displayed) the format of the other option does not really matter! 😉

[mreynolds389]

I'm confused. Do we log the "SESSION" statement or not? If so, are you objecting to my suggestion of breaking it up into 4 key/value pairs?

Also in the SESSION log line you have "... OID=SID" --> "1.1.1.1.1=STID_MY_ID". So does the OID directly have something to do with the SID, or can they be separated like I suggested? When I read over the RFC they seem unrelated, but you have them connected with a "=". Am I making sense, or am I confusing this more?

[mreynolds389]

I agree with Mark about the quote. about the oid and the sid, if I understand rightly the internet draft, the oid is the format syntax of the sid so they are related but not connected But anyway as we plan to go to option 3 (i.e: only the sid is displayed) the format of the other option does not really matter! 😉

:-) Yup. Only adding the sid to the RESULT line would make all my other concerns go away.

[progier389]

FYI In the design document, Thierry explored different alternatives about how to format the log
Then he choose the one that that provides useful data and limit the performance impact (i.e: option 3)
So no, the SESSION line will not be displayed.

[progier389]

Sorry, Looks like our answer collided ! 😄

[mreynolds389]

When I read over the RFC they seem unrelated, but you have them connected with a "=".

Pierre, you are right, they are related in a sense. The oid defines how the source hostname AND the sid are formatted (so not just the sid). Well if we keep the SESSION log line I still think it should be separated, but it sounds like the SESSION line is going to be dropped so this is all moot. :-)

[tbordaz]

The draft provides 4 data (strings).

• ip address is useless as we already have it in the connection info. So I propose to not log it
• hostname (client) would be interesting but IMHO we can retrieve it with ip address. So I propose to not log it.
• formatOID, there is a good example here with 'username'. In short the session_id=abcd is a user name and you may display it in a smarter log 'username=abcd'. I think that most application will want to log internal tracking info, so what is interesting is the value not the description. So I propose to not log it.
• sessionTrackingID. IMHO it is the core of the sessionTracking and the only one I propose to log. I propose to log it in the RESULT line.

I realize that the current design is confusing. I will try to make this proposal more clear ;)

[mreynolds389]

• sessionTrackingID. IMHO it is the core of the sessionTracking and the only one I propose to log. I propose to log it in the RESULT line.

I realize that the current design is confusing. I will try to make this proposal more clear ;)

No worries, and I agree that the sid being in the RESULT line is sufficient especially since we don't use the other info in the control.