The commands.log response classifier used a "passw" text match on the request arguments. A secret whose name has no such text passed the check, so a read of an authentication key, a privacy key or the snmpc site value logged its bare value in the response. A command that expands an argument also passed the check: nodels with a table name returns every column of the table, and lsdef returns attributes that the request never names. The daemon also ran redact_password over the whole connection log on each request, so the redactor split at the first request of the connection and the change signal swept the text of earlier requests and responses. Add secret_in_request. The routine reports a request that names a secret attribute, selects a secret site key, or dumps a table that owns a secret column through tabdump or nodels, from the same secret set that the argument redaction uses. The response classifier calls it, so the response of such a request logs as redacted. Add secret_in_response. The routine reports response text that holds "passw" or a secret attribute name in assignment or column form. The response finalizer calls it in place of the bare text match, so an expanded listing that carries an authentication key or a product key logs as redacted even when the request never names it. The lsvm response is the directory entry, whose passwords are positional, so the classifier marks the command itself. Build each request segment alone, redact the segment, and then append it to the connection log. The redactor now always sees the current command, and the change signal covers only the current request.
xCAT
xCAT is a toolkit for deployment and administration of clusters of all sizes.
The xCAT sunset was only a quick eclipse
Dear xCAT Community,
The xCAT sunset has changed course. VersatusHPC has been invited to join the xCAT Consortium, and future development will move toward direct upstream contributions coordinated with the Consortium and its existing member companies.
That matters most for Enterprise Linux 10 (EL10). EL10 support is coming to xCAT, restoring a future operating-system path for sites that still rely on xCAT. This is an important change from the previous sunset guidance, where the lack of an EL10 path was one of the strongest reasons to move away from xCAT.
The xCAT Consortium continues to recommend Confluent as the long-term successor to xCAT, and that remains the Consortium position. Users planning new cluster-management deployments should evaluate Confluent and its xCAT comparison documentation.
At the same time, xCAT is no longer sunsetted. The Consortium and participating companies will continue updating xCAT while there is community and user demand for it.
In summary:
- xCAT development is continuing upstream through the Consortium and participating companies.
- Enterprise Linux 10 support is coming.
- Confluent remains the Consortium-recommended successor and migration path.
- xCAT updates will continue while there is community and user demand.
We want to thank the xCAT Consortium and community for keeping this project moving. The sun went behind the moon for a moment, but xCAT is still here.
For more information on Confluent and how to get started, please visit the Confluent: Project Page, Documentation or Confluent vs xCAT comparison.
With thanks,
The xCAT Consortium
Documentation
xCAT Documentation is hosted on Read The Docs: https://xcat-docs.readthedocs.io
Status
| xCAT Version | Build Status |
|---|---|
| Latest (master branch) | |
| Stable (latest release) |
Looking for older versions?
Open Source License
xCAT is made available under the EPL license: https://opensource.org/licenses/eclipse-1.0.php
Developers
Want to help? Check out the developers guide!