SQL utility scripts should do more error checking

[ezyang]

For example, if the .sql/my.cnf file is missing, get-password returns no output and get-next-database spews a bunch of undefined index errors. Make this code more robust.

[adehnert]

For some reason, autoinstalls into the UA locker seem to spew some junk:

fs: You don't have the required access rights on '/mit/ua/.sql'
fs: You don't have the required access rights on '/mit/ua/.sql'
fs: You don't have the required access rights on '.'
fs: You don't have the required access rights on '.'
fs: You don't have the required access rights on '.'
fs: You don't have the required access rights on '.'

Given the filename, I'm betting it's because either daemon.sql doesn't have bits, or the account I'm installing with doesn't have admin there. (Yes, the ua locker has annoying permissions. I'm halfway just ranting.)

The autoinstall seems to work, though.

[mitchb]

Replying to adehnert:

For some reason, autoinstalls into the UA locker seem to spew some junk:

fs: You don't have the required access rights on '/mit/ua/.sql'
fs: You don't have the required access rights on '/mit/ua/.sql'
fs: You don't have the required access rights on '.'
fs: You don't have the required access rights on '.'
fs: You don't have the required access rights on '.'
fs: You don't have the required access rights on '.'

Given the filename, I'm betting it's because either daemon.sql doesn't have bits, or the account I'm installing with doesn't have admin there. (Yes, the ua locker has annoying permissions. I'm halfway just ranting.)

The autoinstall seems to work, though.

This is completely unrelated to this ticket, but I don't think Trac gives me rope to punt it. So, if someone's dealing with this ticket, basically disregard it. But for completeness, what Alex is seeing is from lines 141-142 and 170-173 of onathena, which tries to forcibly fix up (lock down) permissions on ~locker/.sql and ~locker/web_scripts_tmp during any autoinstall. Nothing to do with the SQL utility scripts at all.

This would happen and the autoinstall would still succeed if the installing user had 'a' on the top of the locker (so could ssh to scripts), but didn't have 'a' in .sql or web_scripts_tmp. That's not supposed to happen - if you're an administrator of the locker, we expect you to have administrative bits in the Scripts portions of it, and if you don't, it's because you made an unsupported change. The alternative would be to bomb out of the install because of this, when clearly if you know what you're doing, the install will otherwise succeed, so I claim ENOTABUG/UNSUPPORTED.