New Domino on Linux diagnostic script
Daniel Nashed – 27 May 2025 23:04:00
This is still work in progress. But I am working on it since Engage.
I had a server hang in the middle of the night, which was hard to to troubleshoot from remote from my notebook.
it would not have been easier on a Windows machine. But now it is going to be easier on Linux than on Windows.
I am adding a diagnostic menu the Domino Start script. It's going to be a separate script called from the start script.
The idea is to collect data and have an alternate way to transfer data -- even if the Domino server is down.
First transfer is option is using SMTP mail via nshmailx.
But if the files are getting bigger we might need another option. For example SCP.
Using SCP would not require nshmailx, but would not be a convenient.
Maybe an upload agent would be a good idea, but would need an agent.
There is probably not a once size that fits all.
What do you think?
- Comments [5]
1Massimo Nadalin 27.05.2025 6:55:11 New Domino on Linux diagnostic script
What about zip all the diagnostic files and put the archive in the domino/html directory?
A password would keep it safe.
It'd be the most convenient way to get it from almost anywhere, only after the HTTP Server will be restarted though. Unless you put it somewhere else accessible from the reverse proxy (if any)...
2Daniel Nashed 27.05.2025 9:26:47 New Domino on Linux diagnostic script
Hi Massimo,
HTML directory is a good idea. But we would need to setup security.
The HTML directory is easy to write from the server from command line.
But yes the Domino server still needs to run to have this working.
And not every server has HTTP started. Protecting HTTP would be important.
I think we need multiple flexible, configurable options.
3Marcus Goesken 28.05.2025 7:04:18 New Domino on Linux diagnostic script
Hi Daniel and Massimo,
to extend Massimo's idea:
have another parallel running Apache/Nginx on the system with another port and store the files (secured) on that server. Or maybe configure this separate server to serve ports 80+443 and be a reverse proxy in front of the Domino server. Forward all traffic to the Domino except a special directory that contains the zipped content.
4Daniel Nashed 28.05.2025 8:40:42 New Domino on Linux diagnostic script
@Marcus,
I don't think we want extra configuration on a Domino server opening the server to risks of data loss.
And I don't want to introduce new dependencies for getting diagnostic data.
We can send the data to a central server where it is uploaded to a database.
The challenge with the same server is that the server could be down. But also uploading the data via an agent on the same server could be an option.
A database to collect diagnostic information without the need to access the local file-system on the Domino server.
It's not that I am out of ideas how to get the data with external tools. I am looking for the right way that would work for most admins.
I looked into scp and rsync to centrally localte the files. And I just looked into WebDAV as another way to get access to files.
There are many options. But adding NGINX on top exposing the data isn't what I would want to do.
-- Daniel
5Massimo Nadalin 28.05.2025 10:25:38 New Domino on Linux diagnostic script
In my humble opinion the script should implement:
- zip diagnostics (on/off)
- (optional) protect zip file with a password (on/off) the argument (optional as well) is the actual password, when not provided it creates a random one, printed out on the console
- zip destination path, defaults to domino/html. Can be anything else (apache/nginx root directory or any other location for scp/webdav subsequent access)
- as alternative to zip destination path: use standalone server (socat/ncat), which runs a temporary http server providing only the created zip file, any keystroke will kill the http server. Just as the the -standalone server of the acme.sh script (which is great).
6Daniel Nashed 28.05.2025 20:43:00 New Domino on Linux diagnostic script
Hi Massimo,
I don't want to open anthing new. I want to push data somewhere.
For example use scp to a central server. store it into a database etc.
ZIP is not a Linux native format. I would prefer tar on Linux.
By the way Windows has native tar built in, too.
ZIP encryption isn't enterprise style encryption.
I thought more about S/MIME for mail or PGP for files.
Private/Public key encryption sounds like the better plan.
I thought about adding S/MIME support to nshmailx.
PGP is native on Linux... But depending on the recipient side S/MIME would be easier to consume if it is mail.