WFA 3.0P2 - log settings for Active Directory

[jauling_chou]

Hello,

Since upgrading to WFA 3.0P2 back in August 2015, we've had to disable Active Directory authentication. If we attempt to enable it, WFA starts generating huge log files, almost 5MB per every few minutes.

I've attempted to open a case for this, but its getting very little traction.

Does anyone have any hints as to what or where this logging might be configured? I'm hoping there is some knob to tweak as opposed to having this embedded in the code somewhere.

Thanks!

[marzec]

Please PM me the case number.

Thanks

Alex

[sinhaa]

@jauling_chou

If you upgrade your WFA to  WFA3.1P2 or WFA4.0RC1 then you wouldn't face this issue. I would highly recommend that you upgrade your WFA. The new versions have many new features and fixes which will improve your WFA experience. 

But for any reason you don't want to upgrade and stay on WFA3.0P2, you can set the WFA LDAP log level using the following:

1. Login WFA Windows server and go to \WFA\jboss\standalone\configuration

2. Open file standalone-full.xml using some text editor like Notepad++

3. Search for the below and make the changes in the level from INFO to WARN or ERROR

Old

====

<logger category="com.netapp.wfa.ldap">
<level name="INFO"/>
<handlers>
<handler name="WFA_LDAP"/>
</handlers>
</logger>

New

====

<logger category="com.netapp.wfa.ldap">
<level name="WARN"/>
<handlers>
<handler name="WFA_LDAP"/>
</handlers>
</logger>

4. Restart the WFA server service.

Let me know if this works for you.

sinhaa

[jauling_chou]

Unfortunately this stanza is already set to WARN, so it doesn't seem to be that easy.

I will try to play around with log rention, in hopes that it can limit the diskspace used. I'm not sure if we want to upgrade to WFA 3.1 or higher, as it most likely will require a significant amount of testing and possibly some workflow/finder/filter rewriting. The amount of effort required seems a bit much to just enable AD auth!

Will respond with my findings, thanks.

[sinhaa]

@jauling_chou

I don't have the case ID to know the details. I have some questions:

1. Which WFA Log file(s) are getting oversized upon LDAP login? 5MB is not actually too big in my opinion.

2. What kind of messages do you see in the log files? Warning? Errors? Info?

3. Does the LDAP login succeeds? Does it take a long time to succeed?

The log file particular for the LDAP login in wfa_ldap.log. Can you send me the oversized logfile. My email is sinhaa at netapp dot com

sinhaa

[jauling_chou]

---

@sinhaa wrote:

@jauling_chou

I don't have the case ID to know the details. I have some questions:

1. Which WFA Log file(s) are getting oversized upon LDAP login? 5MB is not actually too big in my opinion.

2. What kind of messages do you see in the log files? Warning? Errors? Info?

3. Does the LDAP login succeeds? Does it take a long time to succeed?

The log file particular for the LDAP login in wfa_ldap.log. Can you send me the oversized logfile. My email is sinhaa at netapp dot com

sinhaa

---

I admit its been a while since I've looked at this. Our workaround back in August 2015 was to just disable Active Directory. It would be great if WFA 3.0 could support direct LDAP, but based on the UI it seems it only takes AD.

Looking at my test WFA 3.0P2 instance, which I have enabled AD, it looks like the wfa_ldap.log files are properly being rotated after 5 files each of which are 5MBytes. I also noticed this test instance had INFO level set for wfa.ldap. I'm embarassed to say that this might be the root cause of the log issue I'm reporting here. Back in August, I may have used the behavior I was seeing in my test WFA instance as possibly how my production instance would also behave. As I stated above, my prod WFA instance has the wfa.ldap log level set to WARN. My test instance was spewing all kinds of AD info into the logs, which I guess is directly related to the INFO level.

I've reset my test WFA instance to log WARN level for LDAP now, and will let it sit for a few days and monitor log rotation. Thank you!