On Mon, Jan 5, 2026 at 6:34 PM William Brown <[email protected]> wrote:
> > That's the intention. And generally, I don't plan it any time soon as it's > the least desired feature. Reindex and fixup tasks? That *might* *be* > sooner, but still it'll be guarded with the switch with the default to > 'false'. > > > Even then, LLM's have been shown to bypass and avoid developer implemented > limits. I'd be very hesitant about this. For example, a reindex task takes > your instance temporarily offline. What if the LLM decides a reindex is > needed before you gave it consent? What if it reindexs all your systems in > parallel rather than one at a time? Even this is potentially an outage in > the making. > Your concern is valid... If those ever get implemented, they'd need explicit confirmation flows, not just a feature flag. But that's a bridge to cross later, if at all. > > > >> >> - Privacy mode - Set LDAP_MCP_EXPOSE_SENSITIVE_DATA=false to anonymize >> output >> >> >> Privacy should be the default IMO, especially given how LLMs may harvest >> data. >> > > It is default to not provide any sensitive data to LLM. It can be turned > off for cases (ideally) when the model is local, for example. > > > Okay, it wasn't clear in how you wrote it. > Yeah, I can see it now. It was the afternoon of December 31st, if that excuses my mistake. :D > Honestly? I don't think we should have MCP anywhere near 389-ds. I know >> that you will have worked a lot on this, and I'm sure there was a "business >> reason" your employer probably wanted you to implement this for. >> >> But as I have said - LDAP is a high value, important, and critical piece >> of infrastructure in many environments. If LDAP stops - the business stops. >> >> To have an MCP/LLM trying to "summarise and advise" about how one of the >> most critical pieces of software in an environment works seems like a >> recipe for disaster. >> >> As a former sysadmin, I would not want MCP anywhere near systems. Systems >> require insight, understanding, and thought to manage. Systems do not need >> "statistically plausible sentence generators". >> >> There are many ways we can make LDAP and 389-ds easier and more >> accessible to administrators, to assist them with understanding the state >> of their systems. But MCP/LLMs are not it. >> > > I appreciate the thoughtful feedback, and I think you raise valid concerns > about AI and critical infrastructure. But I'd push back a bit on the > framing here. > > This isn't about having an LLM "advise" on how to run your directory > service, or make autonomous decisions about your topology. It's a read-only > diagnostic wrapper around lib389. > > Think about what the tool actually does - it calls healthcheck, parses > replication status, looks for unindexed searches in logs (not LLM > parses, lib389 parses, - LLM gets only the 'yes or no' answer - and more if > sensitive is off), gives monitor output. These are things you'd do yourself > with dsconf or by reading documentation. The MCP layer just lets you ask > "are there any unindexed searches?" instead of remembering the exact > incantation to grep the logs or which dsconf subcommand to use. lib389 does > the job and we are making sure it's correctly implemented. The human still > sees the output (and MCP logs for the exact lib389 output). The human still > decides what to do. The human still runs dsconf or edits dse.ldif > themselves. Nothing writes to the directory. > > You're right that LDAP is critical infrastructure. You're right that LLMs > make mistakes. But there's a difference between "AI agent manages your LDAP > topology" and "natural language interface to lib389 that returns diagnostic > information." This is the latter. > > > The concern is that the diagnostic information may be *altered* or > *misrepresented*. This isn't just "calling healthcheck" - it's calling > healthcheck with a transformation layer in between that *can* and *will* > alter that output. And that transformation layer is a "statistically > plausible sentence generator" so your framing of how you make a request can > cause that data to be altered. > > And that's the problem - if the LLM tells you what you want to hear, or > alters the data, it may mask a critical or important detail in it's output. > This prevents the human from being able to intervene, investigate, and > understand the situation. > > > > If your concern is that sysadmins will blindly trust LLM output without > verification - that's a valid concern, but it's also true of any > documentation, any Stack Overflow answer, any vendor support response. The > tool surfaces information; it doesn't replace the judgment needed to act on > it. That judgment was always required - with or without MCP. For > experienced admins who understand what they're looking at, I think it can > be a useful convenience. > > > As an experienced admin, this would be a hinderance - not a convenience. I > would forever be doubting if the surfaced information is truthful or not. > > There are better ways we can surface information about 389-ds to promote > transparency and understanding for our admins and users. Again, in my view, > this is not it. > I don't think it's a hindrance - let me describe the workflow I have in mind. You're investigating an issue. You ask the model to check something (replication status, healthcheck, performance metrics, etc.) across the whole topology. It makes the lib389 calls, gathers the data, and presents you with a graph or table giving you a basic picture of the issue you're investigating. Then you go to dsconf and confirm what you're seeing. (I might add dsconf commands to the output that would produce the same result, where such commands are available.) The admin still does the real work - the MCP layer just gets you to the starting point faster. About plausibility: the key thing is that we have the lib389 data. It's accurate data from the server. Just to make my point - ask any modern LLM to remember a number, then add 200 to it. It'll get it right 99.99% of the time. That's essentially what this does: user asks a question, lib389 gathers accurate data, LLM represents those accurate numbers in a more digestible format. With current tech, there's arguably less chance of error than an unfocused administrator parsing raw output after a night with no sleep. And to be clear - with that information, the admin should do nothing except go to their server with dsconf and continue the investigation there. This doesn't replace that step; it accelerates getting to the specifics of it. In some cases it might save hours, not just minutes. For something simple? No need for the LDAP MCP Assistant. For more complex and specific cases? Can an admin go through the topology manually with dsconf, collect reports, gather attributes, and juggle through all that information for their specific case? Of course they can. Will it be tedious? Probably. We (389 DS devs) might cover some situations where that initial information representation saves time, we might not. But for the cases where it does help, MCP saves a lot of initial kickstarter time for the investigation. The tools will be tested and tuned, and the docs will advise caution. The MCP goal in general is to help engineers design tools that are as precise (hence helpful) as possible. From my testing, I think it provides enough benefit to be used as a helper tool - a "junior admin" you ask for simple tasks, who may save you time in complex data-gathering situations. Regards, Simon > -- > Sincerely, > > William Brown > > Senior Software Engineer, > Identity and Access Management > SUSE Labs, Australia > >
-- _______________________________________________ 389-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
