signup-sql is broken (signup.php is not accessible)

[leee]

signup-sql has been broken for quite a while now.

Looking at ​signup-sql in locker/bin, it calls for ​get-password in sql/bin, which then finally calls for ​/usr/bin/sql-signup, provided all the right switches are hit. (e.g. get-password should be modified to know about the condition where a user could have ~/.sql/my.cnf` and not be signed up, but that's for another ticket).

This complains!

$ /usr/bin/sql-signup
Traceback (most recent call last):
  File "/usr/sbin/sql-signup", line 21, in <module>
    execv(SQLBIN, [SQLBIN, str(user_name), str(user_uid), str(user_gid)])
OSError: [Errno 2] No such file or directory

Looking at it, the only file it would ever possibly play with is the one in the variable SQLBIN, which is /afs/athena.mit.edu/contrib/sql/web_scripts/main/batch/signup.php. I unfortunately am not on sql-acl == scripts-root or sql-locker, so cannot troubleshoot further, but ​attempting to access this file via web yielded a 404, giving a somewhat clear indicator of what is causing our signups to break.

[leee]

andersk went ahead and edited /usr/sbin/sql-signup with the right SQLBIN path, and signups appear to be working now! Thanks, Anders!

Because up to now, users have been attempting to signup and have broken my.cnf's generated for them, we should teach get-password the case where that file exists but is invalid. I believe this can be rectified just by changing the order in which we perform several checks, that is:

We should check https://sql.mit.edu/main/do/batch/status?u=username first and foremost to see if a user is signed up for sql. If they are not (case 1), perform an actual sql-signup (the naming scheme here is starting to become a headache), and possibly modify the current case to first remove $cnfPath if it exists since it's presumably "out of date". Then we should perform $cnfinfo = getMyCnfInfo() as the check for case 0, since if an account exists, the information that comes from my.cnf is thought to be valid.

(in reality though, perhaps all of this should be replaced with remctls, but I don't know what the best practice/recommendation here would be).