Troubleshooting Tips for CodeTrack v.0.98 Step 0 (pre-troubleshooting) Create a simple php file in the codetrack directory containing phpinfo(); If you can't see this in a browser, then get help. Something is seriously broken (or maybe trivial-but-vital). 1. Re-read the permissions instructions in INSTALL.txt (95% of CodeTrack problems are related to overly-restrictive permissions. Apache *must* have read priveleges for all fies, read+write for all xml files, and read+write+execute on all directories. On most Unixes, this means that the higher level directories must be similarly opened. See the Purple book (formerly the Red book) for more info. Here is an example of a CodeTrack installation with reasonable permissions set (note the first two directory entries): [root@beyach codetrack]# ls -lh total 628k drwx------ 2 nobody nobody 4.0k Mar 31 20:13 attachments drwx------ 2 nobody nobody 4.0k Apr 1 22:36 backups -rw------- 1 nobody nobody 37 Mar 10 19:26 blue.gif -rw------- 1 nobody nobody 442 Mar 21 19:51 bugform_prevalidate.js -rw------- 1 nobody nobody 1.5k Mar 31 20:32 bugs.dtd -rw------- 1 nobody nobody 107k Apr 1 23:24 bugs.xml -rw------- 1 nobody nobody 107k Apr 1 23:16 codetrack.php -rw------- 1 nobody nobody 355 Mar 10 19:26 email.gif -rw------- 1 nobody nobody 5.3k Mar 23 22:23 form_validate.js -rw------- 1 nobody nobody 13k Mar 18 19:41 help.html -rw------- 1 nobody nobody 95 Feb 9 15:34 index.html -rw------- 1 nobody nobody 990 Feb 9 15:37 login.css -rw------- 1 nobody nobody 643 Mar 10 19:26 login_validate.js -rw------- 1 nobody nobody 3.4k Mar 10 19:26 main.css -rw------- 1 nobody nobody 1.2k Mar 24 23:00 permissions.xml -rw------- 1 nobody nobody 463 Mar 10 19:26 projectform_prevalidate.js -rw------- 1 nobody nobody 2.0k Mar 21 20:35 projects.xml -rw------- 1 nobody nobody 648 Mar 10 19:26 userform_prevalidate.js -rw------- 1 nobody nobody 829 Mar 31 20:34 users.dtd -rw------- 1 nobody nobody 36k Apr 1 22:59 users.xml For a slightly more secure setup, here is an example of a CodeTrack installation with stricter permissions set (note that only the XML files and directories are writeable): [root@beyach codetrack]# ls -lh total 628k drwx------ 2 nobody nobody 4.0k Mar 31 20:13 attachments drwx------ 2 nobody nobody 4.0k Apr 1 22:36 backups -r-------- 1 nobody nobody 37 Mar 10 19:26 blue.gif -r-------- 1 nobody nobody 442 Mar 21 19:51 bugform_prevalidate.js -r-------- 1 nobody nobody 1.5k Mar 31 20:32 bugs.dtd -rw------- 1 nobody nobody 107k Apr 1 23:24 bugs.xml -r-------- 1 nobody nobody 107k Apr 1 23:16 codetrack.php -r-------- 1 nobody nobody 355 Mar 10 19:26 email.gif -r-------- 1 nobody nobody 5.3k Mar 23 22:23 form_validate.js -r-------- 1 nobody nobody 13k Mar 18 19:41 help.html -r-------- 1 nobody nobody 95 Feb 9 15:34 index.html -r-------- 1 nobody nobody 990 Feb 9 15:37 login.css -r-------- 1 nobody nobody 643 Mar 10 19:26 login_validate.js -r-------- 1 nobody nobody 3.4k Mar 10 19:26 main.css -rw------- 1 nobody nobody 1.2k Mar 24 23:00 permissions.xml -r-------- 1 nobody nobody 463 Mar 10 19:26 projectform_prevalidate.js -rw------- 1 nobody nobody 2.0k Mar 21 20:35 projects.xml -r-------- 1 nobody nobody 648 Mar 10 19:26 userform_prevalidate.js -r-------- 1 nobody nobody 829 Mar 31 20:34 users.dtd -rw------- 1 nobody nobody 36k Apr 1 22:59 users.xml 2. Verify that your hostname is correct. Many folks have a broken Linux installation, but just didn't realize it yet. If you want to use e-mail, try typing "hostname" or "hostname --fqdn" at a command prompt. If it reads localhost or localhost.localdomain, this is wrong. With a setup like this, Apache is reporting a bogus hostname (unless you are truly running it *only* for local development), and this can affect SSL, cookies, and definately e-mail delivery. Most company's e-mail servers would reject mail originating from "localhost.localdomain" as a bogus address, possibly dropping messages because of spam. This can be the case even when you are sending mail to other users *inside* your own organization! 3. Check the mail log. On Linux, it's often located at: /var/log/maillog Do a "tail" on your mail log for a good breakdown on what happened: tail /var/log/maillog If you see entries referring to "timeout", this may be caused by draconian firewall rules, or a spam filter. If you see warnings about untrusted user "nobody" changing the origin address, this is not necessarily wrong, but means that the user running your webserver is not on the sendmail (or qmail) trusted user list. I don't recommend you pursue this path unless you have ruled out the more common problems with invalid hostname or DNS (see below). 4. Rule out the possibility of a broken DNS. From a command prompt, try: nslookup name.of.your.machine If you get something other than what you expect, talk to your local system admin. This is critical. 5. Another thing to try is to set up a Hotmail or Yahoo Mail account, and try setting one of your users up with an email address there. As of early 2002, these organizations block virtually nothing, and will usually allow very broken mail messages in. If this works, then revisit your hostname settings, along with the return email address setting in codetrack.php: DEFINE ("CODETRACK_RETURN_ADDRESS", "me@mycompany.org" ); In the vast majority of cases, this is the culprit. If you've tried everything else, and are running a PHP version 4.05 or higher, another possibility is to invoke the "envelope return address" -- ONLY available on non-Windows PHP from version 4.05 higher: DEFINE ( "USE_EXTRA_MAIL_HEADER", TRUE ); Note that this is not a "magic bullet" -- usually it is a bandaid of last resort for draconian anti-spam SMTP servers, and it WILL generate (benign) warnings in your mail log. 6. Windows users -- re-read INSTALL.txt for setting up php.ini the first time for proper mail delivery. Note that you do NOT have to run a mail server, and can often use your ISP's SMTP box as an outbound relay.