OK, to clarify a few points about the userlog in the Webadmin Management main menu:
* Successful logins and storage changes come directly from /var/log/confd.log (and, on a not-so-busy machine, older Confd log files). That's why successful logins and storage changes show up without any delay.
* The number of userlog entries regarding sucessful logins is limited to 20. This number is configurable in the backend, but it is fixed in the frontend. That's why the oldest successful logins can fall off the list even while older failed logins are still shown.
* Failed logins come from a completely different source, via the AUA (Astaro Authentication Agent), the reporting database framework, the inline reporting framework and the file /var/log/reporting/inline/management.ph. That is why they are completely independent, show up with a short delay (typically on the order of 15 minutes), and stay around longer.
* An increasing number of failed logins does not reduce the number of successful logins that are shown. As fas as i know, the number of failed logins is limited independently (to 25?), but don't take my word for that, i'm not a reporting specialist.
* Do not waste your time testing the userlog on HA/cluster system. By chance, it mostly works, but HA/cluster was completely forgotten when designing the userlog. At some point, i need to check the design of the userlog with respect to HA/cluster systems, anyway.
You might wonder why i don't take the failed logins from the Confd log as well, avoiding the typical reporting delay. That would work for failed webadmin logins, but not for failed logins in other authentication contexts, for example remote access and VPNs.
OK, to clarify a few points about the userlog in the Webadmin Management main menu:
* Successful logins and storage changes come directly from /var/log/confd.log (and, on a not-so-busy machine, older Confd log files). That's why successful logins and storage changes show up without any delay.
* The number of userlog entries regarding sucessful logins is limited to 20. This number is configurable in the backend, but it is fixed in the frontend. That's why the oldest successful logins can fall off the list even while older failed logins are still shown.
* Failed logins come from a completely different source, via the AUA (Astaro Authentication Agent), the reporting database framework, the inline reporting framework and the file /var/log/reporting/inline/management.ph. That is why they are completely independent, show up with a short delay (typically on the order of 15 minutes), and stay around longer.
* An increasing number of failed logins does not reduce the number of successful logins that are shown. As fas as i know, the number of failed logins is limited independently (to 25?), but don't take my word for that, i'm not a reporting specialist.
* Do not waste your time testing the userlog on HA/cluster system. By chance, it mostly works, but HA/cluster was completely forgotten when designing the userlog. At some point, i need to check the design of the userlog with respect to HA/cluster systems, anyway.
You might wonder why i don't take the failed logins from the Confd log as well, avoiding the typical reporting delay. That would work for failed webadmin logins, but not for failed logins in other authentication contexts, for example remote access and VPNs.
