roll with it. however, I see another danger:
At some point, admins will get lazy and not want to log in and restart the thing again and again, so they hardcode the password somewhere.
rule 1: make sure it is stable and does not need much restarting.
In most cases, you log the error, then die. And a process-monitor/helpdesk should pick up it's absence.
In some cases, the daemon needs to be up just to tell other applications it is down. (like a webserver without database backend)
Some ideas for the latter case:
Daemon detects it starts password-less, and without a TTY to ask for $pwd=<STDIN>
It does $0 = $0 . ' - NOPASSWORD' so you can see with ps -ef the state it is in.
You run a local small sendpwd perlscript that:
0. Does not show the password with ps -ef
1. sends the daemon a SIGUSR1, the daemon then creates a named pipe. for example: /tmp/fifo
2. Once the daemon gets a valid password it closes and deletes the pipe.
3. The daemon updates its process name by removing the "- NOPASSWORD" it had with $0 =~ s/ - NOPASSWORD$//;
The obvious solution was a special https web-page where you can input your password, but that was deemed undesirable by audit. figures.
nb: because nobody logged into the machine, there was no audit trace of an action. (yes, all history files were copied to a security server)
|