Tanmay Singhal via Mailman-Developers writes: > I also became very interested in the Log Access from the Web UI > project idea, > > From what I can see, Mailman Core writes logs using Python’s > logging framework to files under the configured "log_dir" > (typically something like /var/log/mailman).
Note that in many cases you really want to track MTA logs as well. Because MUA logs are typically quite voluminous, these should be a separate option, fail gracefully if the `mailman` user doesn't have permission to access system logs, and be paged. > Since some log messages reference the list FQDN, it seems that log > entries might be scoped for list owners or domain admins by > filtering entries that mention their lists or domains. > > Should the UI aim to support something like real-time log viewing > (similar to tail -f), That would be a nice shiny option, but I doubt it would be that useful in applications: people who need that are going to have the ear of root (and if they don't, they have bigger problems than the lack of a fancy web monitor). > or is the expectation that administrators would primarily browse > recent log entries (e.g. the last N lines or paginated logs)? Yes (to both), but it would be interesting to keep track of the position in the log file and update in a scrollable window at the end. This might be difficult in the case of systemd's logs (although I've already thought of one way to do it). > While thinking about the design, I realized that in some > deployments Postorius and Mailman Core may not share the same host > or filesystem. Is that a deployment pattern that is commonly seen > with Mailman installations? I don't know how common that is, but all the cases I know of are either docker containers on a single host, or run by serious mail professionals. "Let them fight!" > Because of that, I wanted to ask about the intended architectural > direction for this feature. Should the initial implementation > assume that Postorius can read Mailman log files directly from the > filesystem, or would it be preferable for log access to eventually > be exposed through Mailman Core itself (for example via the REST > API)? The latter, since Postorius is not required and in fact we encourage development of alternatives. > I’m also trying to understand the expectations around > filtering. Since Mailman logs are not structured and may contain > information unrelated to the list being viewed, is the expectation > that log scoping will rely primarily on parsing the log text, Yes, and best effort on the parsing, I've done some of this kind of thing and perfection is maybe not NP-hard, but it's not easy. > or is there interest in introducing more explicit identification of > lists/domains in log records (for example through structured > logging) over time? If there's time or you do an extended time period. Otherwise out of scope. > Another point I was wondering about is the scope of logs this > feature should expose. The project description mentions that site > admins may want to access information from the MTA or web server as > well. Should the initial implementation focus only on Mailman’s own > logs, or is there interest in supporting other system logs in the > UI as well? Systems logs are in scope, but as mentioned above you may assume a single host with accessible file system and/or systemd journalctl. Need to check that the file system is accessible and the permissions allow access, and if not, fail gracefully. > Finally, while reviewing the project ideas, I also noticed the > Domain Administration project. If the log access project is > considered significantly more complex or architecture heavy, would > working on the Domain Administration feature be a more suitable > project for GSoC? I don't think log access scoped to a single filesystem is hard. It's actually almost beginner-friendly in the sense that it requires basically zero Mailman knowledge. It does require Django, and Javascript (for tail'ing and that kind of real-time feature) is very desirable, I suspect. Domain Administration is quite Mailman-intensive. You need to know both the specifics of existing templates, views, and access controls, you need to access REST API endpoints and possibly create new ones, and you may need to extend the domain and domain owner models. I would say the learning curve is quite slow at the beginning, maybe several weeks to implement one feature. But once you've implemented two, you can probably rough out a couple more per day (tests and docs will take more time, as always). Steve -- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan _______________________________________________ Mailman-Developers mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/mailman-developers.python.org/ Mailman FAQ: https://wiki.list.org/x/AgA3 Security Policy: https://wiki.list.org/x/QIA9
