Lin 2 :(

Lin 2 was KIA for about a week:

(Yes, that's a scorch mark in the middle of the CPU)

But thanks to some hard work on VPiattelli's part, he's back in action. Lin 2 will be hanging out with us for a month while we bring it back up to speed and run Ruby on Rails experiments on it. Once that is complete we'll re-image Lin's hard drive and move that over the Lin 2. Things should go a lot smoother now that they have the same hardware:

• Asus A7V8X-X
  
• AMD XP2600
  
• 1 Seagate Barracuda 80GB Hardrive Model ST380013A
  
• 3DForce2 MX-64 DDR-TV -- NVIDIA GeForce2 MX400
  
• CD-Rom Samsung 52x Rom (CD R/RW -- OptoRite 52ROM/52W/32RW on the Lin 2)
  
• Legacy Floppy
  
• SuSE 9.0 Professional

Updated to phpBB-2.0.21

No hunk problems this time either.

This release:

# [Fix] Changes to random number generator code to explicitly truncate the length of the string
# [Fix] Quoting on boards with HTML enabled
# [Fix] Special characters on boards with HTML enabled
# [Fix] Redirect to list if cancelling deletion of ranks, smilies or word censors
# [Fix] Missing error message if an inactive user tried to login (Bug #1598)
# [Fix] Do not alter post counts when just removing a poll (Bug #1602)
# [Fix] Correct error in removal of old session keys
# [Fix] Changed filtering of short search terms
# [Sec] Improved filtering on language selection (also addresses a number of bug reports related to missing languages)
# [Change] Backported more efficient highlighting code from Olympus
# [Change] Backported zlib emulation code so that there is only a single confirmation image even if zlib is not available

No Longer Feeling Like I'm Blind

Used "sax2" from the command line to bring up a configuration screen where I set the resolution to 1024x768 on lin2.

Performed Manual Backup To Failover

Successfully accomplished using directions at http://bkserverlog.blogspot.com/2005/05/backup-to-failover.html

Updated phpBB to 2.0.20

* Prevent login attempts from incrementing for inactive users
* Do not check maximum login attempts on re-authentication to the admin panel - tomknight
* Regenerate session keys on password change
* retrieving category rows in index.php (Bug #90)
* improved index performance by determining the permissions before iterating through all forums (Bug #91)
* Better handling of short usernames within the search (bug #105)
* Send a no-cache header on admin pages as well as normal board pages (Bug #149)
* Apply word censors to the message when quoting it (Bug #405)

* Improved performance of query in admin_groups (Bug #753)
* Workaround for an issue in either PHP or MSSQL resulting in a space being returned instead of an empty string (bug #830)
* Correct use of default_style config value (Bug #861)
* Replace unneeded unset calls in admin_db_utilities.php - vanderaj
* Improved error handling in modcp.php
* Improved handling of forums to which the user does not have any explicit permissions - vanderaj
* Assorted fixes and cleanup of admin_ranks.php, now requires confirmation of deletions
* Assorted fixes and cleanup of admin_words.php, now requires confirmation of deletions
* Addition and editing of smilies can no longer be performed via GET, now requires confirmation of deletions
* Escape group names in admin_groups.php
* Replace strip_tags with htmlspecialchars in private message subject
* Some changes to HTML handling if enabled
* Escape any special characters in reverse dns - Anthrax101
* Typecast poll id values - Anthrax101
* Added configurable search flood control to reduce the effect of DoS style attacks
* Changed the way we create "random" values for use as keys - chinchilla/Anthrax101
* Enabled Visual Confirmation by default
* Changed handling of the case where a selected style
doesn't exist in the database
* Changed handling of topic pruning to improve performance
* Changed default forum permissions to only allow
registered users to post in new forums

Restarting Apache with a funny pid error

A power flux or some other anomaly caused the server to go down this afternoon. Once the power came back up, everything email got going immediately, but apache had some issues. It seems that the pid used by apache was reused by mysql which caused apache to think that it was running when it really wasn't and not want to restart. The resolve the issue I had to kill mysql, then start apache, then start mysql back up.

How did we figure out this was the problem?

1. ps -elf | grep apache did not reveal any apache processes running. This makes sense because the web site was down.
   
2. apachectl start told me that apache was already cranking away on pid XX
   
3. checking out the apache logs located in /opt/apache/logs revealed that no commands were reaching the logs.
   
4. I looked up the pid using ps again and saw that mysql was the process that held that pid.
   
5. Killed mysql using the command ./mysqladmin -u root -p shutdown. mysqladmin is located in /usr/local/mysql/bin/ and the password is the root password for mysql.
   
6. That command killed mysql and freed the pid apache thought it owned. apachectl start got apache rolling again. The only thing left to do is start mysql back up.
   
7. Since I didn't know the command to start mysql, I had to look in the boot.local file stored in /etc/init.d. This file has startup procedures for our server, one of which is mysql.
   
8. The command /usr/local/mysql/bin/safe_mysqld & will kick off mysql and get everything running back to normal.
   

So, to review, the important stuff to remember:

• Where's my apache log?
  
• ps -elf is the easy way to find a process
  
• apachectl is your gateway to manage apache
  
• mysqladmin allows you to stop mySql (among other things)
  
• boot.local houses the command to start mysql, and it is also written above.

Upgraded to phpBB-2.0.19

I upgraded to 2.0.19 today with no problems. Here's the changelog from the devs:

The changelog (contained within this release) is as follows:

- corrected index on session keys table under MS SQL
- added session keys table to backup
- delete session keys entries when deleting user
- changes to support MySQL 5.0
- changes to some of the admin files to improve efficiency and remove a potential error condition when building the menu
- change truncation of username length in usercp_register.php - BFUK
- incorrect path to avatars in admin_users.php (Bug #667)
- fixed get_userdata to support correct sql escaping (non-mysql
dbs) - jarnaez
- fixed captcha for those not having the zlib extension enabled
- Placed version information above who is online in admin panel for better visual presence
- fixed XSS issue (only valid for Internet Explorer) within the url bbcode
- fixed XSS issue (only valid for Internet Explorer) if html tags are allowed and enabled
- added configurable maximum login attempts to prevent dictionary attacks

Simscan update again - 1.2

I updated Simscan to 1.2 due to better debugging info, and I turned debugging on by setting the environment variable SIMSCAN_DEBUG in tcp.smtp. You can find it if you scroll to the bottom of the file.

After doing a lot of research, here's basically what's going on:

TCPServer is a generic tcp server process which qmail-smtp is running (or vice versa) that accepts connections given the constraints laid out in /home/vpopmail/etc/tcp.smtp.cdb, which is a database compiled from /home/vpopmail/etc/tcp.smtp. Whenever a message is received, it is passed off to simscan, a C program which calls clamav, our antivirus program, and spamc, a client function which calls spamd, a daemon that does our spamassassin processing. If a message is determined to be spam by the spamc process, then simscan (which is our "governing" process) is supposed to place it in quarantine. For some reason, for certain emails this is not happening.

Specifically, these emails generally have very high spamminess scores, are listed as message (unknown) in the spamd logs, and cause no quarantine message in the /var/log/qmail/smtpd logs.

Also, if you want to see the right times, just run readlog in the log directory and it will list current with the correct times, where current is the most recent log.

I'm waiting for another bounce message in postmaster to indicate that the fake hotmail address this bouncing spam is coming from has failed to be quarantined again, so I can look in the smtpd logs and see exactly what simscan is doing. What I'm really hoping for is an inconsistent "CLEAN" message, where the score clearly doesn't merit a CLEAN so I can send it to the simscan authors.