Server Log

Lin 2 :(

2006-06-13T13:08:00.000-05:00

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

2006-06-08T10:16:00.000-05:00

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

2006-04-14T08:26:00.000-05:00

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

2006-04-14T08:08:00.000-05:00

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

Updated phpBB to 2.0.20

2006-04-11T13:41:00.000-05:00

* 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

2006-02-15T15:50:00.000-05:00

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?

ps -elf | grep apache did not reveal any apache processes running. This makes sense because the web site was down.
apachectl start told me that apache was already cranking away on pid XX
checking out the apache logs located in /opt/apache/logs revealed that no commands were reaching the logs.
I looked up the pid using ps again and saw that mysql was the process that held that pid.
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.
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.
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.
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

2005-12-30T16:48:00.000-05:00

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

2005-12-19T19:10:00.000-05:00

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.

Simscan Update

2005-12-18T16:24:00.000-05:00

Updated simscan to 1.1, and changed the simcontrol file so that simscan no longer scans abuse@example.com so that if someone forwards a spam complaint, we won't quarantine it by accident.

I also added postmaster@example.com because recent forwards to it, which weren't getting filtered, were getting filtered by postmaster. Crazy.

To update simcontrol:

/var/qmail/bin/simscanmk
/var/qmail/bin/simscanmk -g
qmailctl cdb <=== might not need

Failing to quarantine, mailing lists getting spammed

2005-12-18T15:42:00.000-05:00

One of our mailing lists got flooded by spam because of some loose permission settings, although it seemed to me that the messages that were being received should have been quarantined, and they weren't. Their scores were well over the threshold for being quarantined, so I decided to investigate the logs.

The /var/log/spamd log has these messages in it: @4000000043a5aef60405abb4 [20458] error: Can't locate Mail/SPF/Query.pm in @INC (etc etc)

So, I'm going to resolve those errors first.

Alright, so I tried to install Mail::SPF::Query by doing the whole download to /src/var/tar thing and then make blah blah, but it had some dependencies missing.

SO

I installed the dependencies using the cpan interface:

cd /root
perl -MCPAN -e shell
install DependencyName::Dependency::etc

and then I said what the heck, I'll just install Mail::SPF::Query with the cpan terminal also, it's cleaner that way.

So I did:

install Mail::SPF::Query <==Note, this command has to be run from the CPAN console.
quit

Everything ran fine, and although the error is no longer appearing, I don't think we solved our problem.

I set all the mailing lists to only accept messages from subscribers.

Manual AWStats Update

2005-12-13T13:49:00.000-05:00

To make sure our bandwidth wasn't getting blitzed and to verify that a percievable slowdown in mail was actually occuring, I manually updated awstats to see what has been going on over the past hour and a half. We have a cron job set up under root to update the statistics log every 12 hours. The new conent went public at about 12:30, just after the midday update.

To manually update awstats enter the following command from the cgi-bin directory:

>./awestats.pl config=www.blah.com -update

Then, simply refresh the stats page in your browser and you'll be good to go.

In case you're curious, you can view any cronjobs that are setup form anywhere by simply running crontab. You can view it via "crontab -e" (for edit). Remember your vi commands when editing the crontab.

SpamAssassin Update

2005-11-24T17:29:00.000-05:00

I upgraded SpamAssassin again, to version 3.1.0. Seemed to go uneventfully, and I restarted qmail and the spamassassin daemon with no problems. I did the same procedure listed for the last SpamAssassin upgrade, which can be found by searching the blog for spamassassin.

To stop and restart Qmail:

qmailctl restart

To stop and restart Spamassassin: (being in the /service directory)

svc -d spamd
svc -u spamd

Sent a test email to myself and checked the headers to confirm that the new version of SpamAssassin was processing.

TO DO:

The same thing on lin2.

phpBB2 upgraded to 2.0.18

2005-11-09T17:09:00.000-05:00

Same thing as last time in terms of problems with the .patch file and comments. Also hand changed some file permissions that I thought were too lenient.

Upgraded Apache and rights changed

2005-09-20T07:32:00.000-05:00

Alright, I upgraded apache http server to version 2.0.54. Here's my kickass technique:

1) Go to Apache site and find out what the link is to download the latest stable Apache http source.
2) go to /var/src/tar, copy and paste the link into the command line and precede it with "wget". So wget http://whatever.
3) server:/var/src/tar -xzvf ./tar/http.2.0.54.etc
4) copy the best runconfigure file from the old extracted source to the new extracted directory
5) go to the new source, run ./runconfigure,
6) run make
7) run make install
8) apachectl restart

Oh and I changed /www/blah.com and /www/blahforsmarties.com to www:www via chmod

Added mod_rewrite to Apache

2005-09-16T16:56:00.000-05:00

1. Added --enable-rewrite=yes to runconfigure_with_mod_rewrite
2. ./runconfigure_with_mod_rewrite
3. make
4. apachectl -stop
5. make install
6. apachectl -start
7.
server:/pathto/apache/bin # ./httpd -l
Compiled in modules:
...
mod_rewrite.c
...

phpBB2 upgraded to 2.0.17

2005-08-31T15:40:00.000-05:00

Unfortunately, I had problems with the .patch file:

server:/invalid.com # patch -cl -d phpBB2 -p1 < phpBB-2.0.16_to_2.0.17.patch
patching file admin/admin_ug_auth.php
Hunk #1 FAILED at 6.
1 out of 6 hunks FAILED -- saving rejects to file admin/admin_ug_auth.php.rej
patching file admin/admin_users.php
patching file includes/bbcode.php
Hunk #1 FAILED at 6.
1 out of 3 hunks FAILED -- saving rejects to file includes/bbcode.php.rej
patching file includes/functions.php
patching file includes/functions_validate.php
patching file includes/usercp_activate.php
patching file includes/usercp_avatar.php
patching file includes/usercp_viewprofile.php
patching file privmsg.php
patching file templates/subSilver/faq_body.tpl
patching file viewtopic.php
server:/invalid.com #

But everything seems to be working still, so I'll ignore this and hope it goes away.

*edit* -- it looks like these conflicts were in comments, so everything should be swell

PHP5 continued

2005-08-23T16:31:00.000-05:00

Well, I had a feeling my brainded install wasn't going to work, and in fact it didn't. There were a lot of problems with it, but the first one was I needed to add a lot of options on ./configure. I vaguely remembered what I did last time to get it work, but happily I had made myself a ./runconfigure file in /var/src/php-4.3.5 with all the ./configure options I used. So I just copied that over to /var/src/php.5.0.4, and tweaked one thing which clearly needed to be tweaked.

Great, so ./runconfigure ./make ./make install right? Not exactly.

I needed to replace my php.ini file with the one provided, and our php.ini file is located in /www/php. Alright, did that.

Changed some options in the php.ini file they provided, like turning off errors and turning on error logging. I might have to change more, but it's not like I rememeber what I changed in the first place, I would have to look up the security paranoia site that I used to originally configure it. Safe mode is currently off, and it was off on our old configuration too.. if it didn't used to be off then that is probably V's doing.

Alright great, now I also check /opt/apache/conf/httpd.conf and fiddle with it a bit as they recommend to in /var/src/php-5.0.4./INSTALL, and I make sure that my httpd.conf settings are correct. I make sure that the LoadModule for the old php4 module is commented out, and that the php5 module is present and that everything is set up right.

I'm not sure exactly what order I did everything, but for a while whenever I tried to pull up a php page in firefox it tried to download it instead of display it, which is not what I wanted. Eventually, it stopped trying to do that. Unsatisfying but hey, it works don't it?

PHP5

2005-08-23T02:03:00.000-05:00

To get the monkey off my back, as far as I know I installed PHP5. If you guys can set up a way to test whether an install actually worked or not, that would be great.

I downloaded the latest source to /var/src/tar, untarred it using tar -xzvf to its own directory, went into the directory and..

./configure
./make
./make install

And it said this after the make install:
Installing PHP SAPI module: cgi
Installing PHP CGI into: /usr/local/bin/
Installing PEAR environment: /usr/local/lib/php/
[PEAR] Archive_Tar - installed: 1.1
[PEAR] Console_Getopt - installed: 1.2
[PEAR] PEAR - installed: 1.3.5
Wrote PEAR system config file at: /usr/local/etc/pear.conf
You may want to add: /usr/local/lib/php to your php.ini include_path
[PEAR] HTML_Template_IT- installed: 1.1
[PEAR] Net_UserAgent_Detect- installed: 2.0.1
[PEAR] XML_RPC - installed: 1.2.2
Installing build environment: /usr/local/lib/php/build/
Installing header files: /usr/local/include/php/
Installing helper programs: /usr/local/bin/
program: phpize
program: php-config
program: phpextdist

Really, this is all I ever do to install something these days, it only gets slightly tricky when I have to patch or restart some service or verify what's going on in some log.

Alright, I restarted apache also for good measure.

apachectl restart

Let's see... all I can think of that might need to be done is a recompilation of apache.

ClamAV encrypted Zip problems

2005-08-03T19:38:00.000-05:00

Alright, found a couple of threads on the net about this:

2005-08-03 10:44:39.966189500 /var/qmail/simscan/blah.txt: Zip module failure ERROR
2005-08-03 11:00:42.586797500 /var/qmail/simscan/blah.txt: Zip module failure ERROR
2005-08-03 11:16:37.144518500 /var/qmail/simscan/blah.txt: Zip module failure ERROR
2005-08-03 11:32:23.426469500 /var/qmail/simscan/blah.txt: Zip module failure ERROR
2005-08-03 11:48:19.257406500 /var/qmail/simscan/blah.txt: Zip module failure ERROR

which was happening for zip files with unusually high encryption. The zip files were being silently bounced because of the error. I upgraded clamav to 0.86.2, using the instructions from the qmail toaster:

Remember, when upgrading clamav USE THE PATCHES or it will crap out on you.

cd /var/src/tar
wget http://shupp.org/software/clamav-0.86.2.tar.gz
wget http://shupp.org/patches/clamav-0.86.2-stderr.patch
wget http://shupp.org/patches/clamav-0.86.2-conf.patch
wget http://shupp.org/patches/clamav-0.86.2-freshclamconf.patch
cd ../
tar -xzf tar/clamav-0.86.2.tar.gz
cd clamav-0.86.2
patch -p0 < ../tar/clamav-0.86.2-stderr.patch
patch -p0 < ../tar/clamav-0.86.2-conf.patch
patch -p0 < ../tar/clamav-0.86.2-freshclamconf.patch
./configure
make
make install

Maintenance Backup Preformed

2005-08-02T09:27:00.000-05:00

Following the instructions on this post, I preformed a backup from the main server to the failover. In case anything went wrong I went ahead and stored the verbose output to a file in the rsync directory called aug2.log. I'm not sure if that was necesary or not, but it seemed like a good idea.

Also, on a side note, to ssh between the main and the failover you have to use the fully qualified name. So, failoverName.failoverName. Also, the failover uses the old root password -- remember that when logging into it.

All seemed to go well.

Checking the SpamAssasin's Bayesian filter

2005-07-13T11:13:00.000-05:00

The sa-learn command is what you seek.

Log in as root and enter the command:
# sa-learn --dump magic

And you should see something similiar to:

0.000	0	3	0	non-token data: bayes db version
0.000	0	6873	0	non-token data: nspam
0.000	0	2029	0	non-token data: nham
0.000	0	165806	0	non-token data: ntokens
0.000	0	1115662783	0	non-token data: oldest atime
0.000	0	1121266571	0	non-token data: newest atime
0.000	0	1121265357	0	non-token data: last journal sync atime
0.000	0	1121236229	0	non-token data: last expiry atime
0.000	0	5529600	0	non-token data: last expire atime delta
0.000	0	1727	0	non-token data: last expire reduction count

Which tells us that the filter has automatically determined that 6873 emails were spam, 2029 were ham, and the rest of the informaiton are just stats about email recieved and sent.

Updated phpBB to 2.0.16

2005-06-30T11:19:00.000-05:00

Used the patch file this time with success after mkeeling pointed out that I wasn't reading directions properly. This helped me avoid having to manually re-add our handful of mods.

______________________
* Fixed critical issue with highlighting - Discovered and fix provided by Ron van Daal
* Url descriptions able to be wrapped over more than one line again
* Fixed bug with eAccelerator in admin_ug_auth.php
* Check new_forum_id for existence in modcp.php - alessnet
* Prevent uploading avatars with no dimensions - Xpert
* Fixed bug in usercp_register.php, forcing avatar file removal without updating avatar informations within the database - HenkPoley
* Fixed bug in admin re-authentication redirect for servers not having index.php as one of their default files set

Website Update

2005-06-28T13:06:00.000-05:00

New mods to website went live. To view them, be sure to refresh your pages. You should see a new menu item and the first ever sub-menu items on the site plus a few CSS changes.

Courier-Imap Upgrade, and rights problems

2005-06-15T12:04:00.000-05:00

It started with a simple thing: I wanted an ftp account that people could use to mess with their web stuff without having to copy stuff manually. So I knew we had a www account that we weren't using, and I changed its home directory to /www, which is where all our web stuff is hosted. For some reason, it took this as a cue to chown everything to www:www recursively in /www, which really bolloxed up our webmail.

I can't make an ftp login for apache, because for security reasons its home directory is set to /dev/null and its default shell is a null shell or something, for security reasons. That way if the apache server is comprimised, it essentially has no rights and no way to log in.

Running the following command fixed everything: chown -R apache:apache * (while in the /www directory). I thought I was going to have to chown something as vpopmail:vchkpw, but apparently not.

In the interim, I thought the problem might be fixed by reinstalling the courier-imap server, and I noticed that we were way out of date, so I upgraded. I think there's a 4.0 out there, but the toaster is still using the 3.x one, and I like the toaster. The toaster is my friend.

1) Upgraded our Courier-Imap, which badly needed it, from 2.2.2 to 3.0.8. I followed the following instructions:

cd /var/src
tar -xjf tar/courier-imap-3.0.8.tar.bz2
cd courier-imap-3.0.8
# build as vpopmail
chown -R vpopmail:vchkpw ../courier-imap-3.0.8
su vpopmail
# configure may take some time...
./configure
# NOTE: RedHat/Fedora users need to add "--with-redhat"

make
exit
make install-strip
make install-configure

cp courier-imap.sysvinit /etc/init.d/courier-imap
chmod 755 /etc/init.d/courier-imap

------------------------------------------------
There were more commands:

ln -s ../init.d/courier-imap /etc/rc0.d/K30courier-imap
ln -s ../init.d/courier-imap /etc/rc1.d/K30courier-imap
ln -s ../init.d/courier-imap /etc/rc2.d/S80courier-imap
ln -s ../init.d/courier-imap /etc/rc3.d/S80courier-imap
ln -s ../init.d/courier-imap /etc/rc4.d/S80courier-imap
ln -s ../init.d/courier-imap /etc/rc5.d/S80courier-imap
ln -s ../init.d/courier-imap /etc/rc6.d/K30courier-imap

But they didn't work and it seemed like they were doing what I had already done, which was configure courier-imap to start when the server starts. We'll find out at the next reboot.

There was also:

Edit /usr/lib/courier-imap/etc/authdaemonrc

* Change authmodulelist="..." to authmodulelist="authvchkpw"

Edit /usr/lib/courier-imap/etc/imapd

* Change 'IMAPDSTART=NO' to 'IMAPDSTART=YES'

Edit /usr/lib/courier-imap/etc/imapd-ssl

* Change 'IMAPDSSLSTART=NO' to 'IMAPDSSLSTART=YES'

But those had already been set, although I double checked. Definitely from the last time I installed courier-imap.

External things

2005-06-15T10:59:00.000-05:00

Well, two things were fixed recently:

1) Our base office ISP scans us regularly with Nessus. The sent us an alert, and we scanned ourselves with Nessus from our mailserver. This was apparently interpreted as an attack, because FTP, SMTP, and HTTP connections from our mailserver to the other office were blocked. A quick email had the problem resolved by the weekend.

2) Our reverse DNS stopped working spontaneously. I called our mail server ISP, and after a day or two they managed to get it back to what it is supposed to be.

3) Also, I went to www.dnsreport.com and noticed that our dns entry wasn't "SPF compatible" I generated the string that we need to get it to work, but our current free DNS provider, EveryDNS.net, doesn't support it for Primary DNS service yet. I emailed them, and they said that as soon as they figured out some data verification issues they would do it for Primary domains in a couple of months.

Huge Update

2005-06-08T15:28:00.000-05:00

I'm not going to list everything I did, but in a nutshell:

I did my best to bring the failover up to speed with all the updates that have happened with the main server, as well as setting up rsync to rsync nearly everything important from the main to failover on command. I added some blocks to the tcp.smtp blocklist, cleaned up the users and directories on the failover, and updated software on the failover that I had updated on the main. I'm sure it could use a serious shakedown, and it still has a weird issue where it pulls up a strange screen when it reboots, but it probably only needs a minor shakeout now to confirm that it is useable as a failover. I'd say the time between main failure and failover takeover is from 30 mins to 2 hours of troubleshooting anything that might not be running properly. It may even be less than that, but I'm certain I've forgotten something.

More blocks

2005-06-07T15:38:00.000-05:00

#Exodus.net in sorbs
64.14.64-95.:deny

#Virginia Jobs
12.8.148.210:deny

/srv

2005-06-06T14:34:00.000-05:00

I deleted the /srv directory on main and failover, with rm -fr /srv. I thought I deleted it before.. so if someone sees it again, it needs to be investigated.

Failover date

2005-06-06T10:59:00.000-05:00

I was doing some experimentation on failover due to mkeeling's suggestion, and I noticed that the date was wayyy off. Like 2015. That's kind of weird. So I fixed the NTP settings on the failover, and rebooted it. Now I have to remember how to sync the hardware clock with the software clock...

hwclock --systohc

There we go, all better.

Updated ClamAV

2005-05-27T10:17:00.000-05:00

I tried updating it by
1) downloading the latest clamav to /var/src/tar,
2) running ./configure,
3) running make install,
4) doing /svc -d /services/clamd (to shut it down)
5) and then /svc -u /services/clamd.

I checked the logs, and just like last time it gave me some weird error:
@400000004297365328694c7c ERROR: LogFile requires full path.
@400000004297365429b87544 ERROR: LogFile requires full path.
@40000000429736552b150b8c ERROR: LogFile requires full path.

So I finally just went to http://www.shupp.org/toaster/, which is where I first got the instructions to install clamav with qmail, and saw that they'd updated to support the latest version. I'm not sure if it's the patches, or the fact that I didn't do "make" before "make install", but it worked. Here's what I did:

(starting in /var/src/tar)
wget http://shupp.org/patches/clamav-0.85.1-stderr.patch
wget http://shupp.org/patches/clamav-0.85.1-conf.patch
wget http://shupp.org/patches/clamav-0.85.1-freshclamconf.patch
cd ../
tar -xzf tar/clamav-0.85.1.tar.gz
cd clamav-0.85.1
patch -p0 < ../tar/clamav-0.85.1-stderr.patch
patch -p0 < ../tar/clamav-0.85.1-conf.patch
patch -p0 < ../tar/clamav-0.85.1-freshclamconf.patch
./configure
make
make install
svc -d /services/clamd
svc -u /services/clamd

I then ran tail /var/log/clamd/current to make sure that it came up properly, and it had.

Backup to Failover

2005-05-24T12:48:00.000-05:00

Currently, backups to the failover are manual. To run them:

1)SSH into main
2)SSH from there into the failover
3)Go to /opt/rsync and run rsync.sh. I modified it so it would have verbose output.

Logs on the Server

2005-05-19T11:50:00.000-05:00

I updated all the supervise scripts that relate to logging, which are located in /var/qmail/supervise/[someservice]/log. The scripts are always called "run" in the log directory. I added a switch, "n50" after multilog so that now, instead of the default 10 old log files, it keeps 50 log files. This is because we needed to go back farther a few days ago, and the log files abruptly ended.

Once I fixed each script, I ran "svc -d . " and then "svc -u . " to restart the log.

Another /24 blocked

2005-05-17T13:52:00.000-05:00

Blocked another /24 in tcp.smtp and recompiled.

70.241.109:deny

Queuelifetime

2005-05-09T15:46:00.000-05:00

Added "queuelifetime" to /var/qmail/control/queuelifetime and put in the value 259200. This means that messages that are sent to bad domains, non-working mailservers, etc will wait in the queue for 3 days instead of a week before sending an error to the user.

Updated Rysnc

2005-05-09T13:46:00.000-05:00

Added the following to both servers' /etc/rsync.conf

[src]
path = /var/src
comment = software source
read only = yes
list = yes
hosts allow = 10.0.0.1 10.0.0.2

[apacheconf]
path = /opt/apache/conf
comment = apache configuration
read only = yes
list = yes
hosts allow = 10.0.0.1 10.0.0.2

And rsynched the failover after testing with the -n flag:

rsync -av --delete main.main::src/ /var/src
rsync -av --delete main.main::apacheconf/ /opt/apache/conf

Upgraded to phpBB-2.0.15

2005-05-09T10:40:00.000-05:00

1. Downloaded .zip of changed files.
2. Started ftpd
3. Unzipped and uploaded changed files.
4. Backed up old phpBB2 directory
5. chowned changed files to apache:apache
6. chmodded changed php files to 644
7. Copied modded files into directory
8. Ran /install/upgrade_to_latest.php
9. Deleted install directory
10. Re-applied changes to login.php
11. Stopped ftpd

_____________________________

Fixed moderator status removal in groupcp.php
Removed newlines after ?> on some files - Thoul
Added admin re-authentication (admin needs to login seperatly to access the ACP) - backported from Olympus
Fixed vulnerability in url/bbcode handling functions - PapaDos and Paul/Zhen-Xjell from CastleCops
Fixed issue in admin/admin_forums.php
Suppressed warning message for fsockopen in /includes/smtp.php - Thoul
Fixed bug in admin/admin_smilies.php (admin is able to add empty smilies) - Exy
Adjusted documents to reflect the urgent need to update the files too (not only running the database update script)
Updated the readme file
Added one new language variable
Added general error if accessing profile for a non-existent user
Changed session id generation to be more unique - Henno Joosep
Fixed bug in highlight code to escape characters correctly
Reversed the 2.0.14 fix for postgresql because it produced more problems than it solves.
Added reference to article written by R45 about case-sensitivity in postgreSQL to the readme file
Fixed bypassing of validate_username on registration - Yen
Empty url/img bbcodes no longer get parsed

Server Log

2005-05-05T13:41:00.000-05:00

Two new additions to tcp.smtp, and will be adding rblsmtpd shortly to more effectively combat spam.

#Some expo or something
64.89.70.9:deny

#Spam from Sprint
207.14.178.:deny

Created a script called recompile in ~vpopmail/etc so we don't keep on going back to remember that recompile line (tcprules tcp.smtp.cdb tcp.smtp.tmp < tcp.smtp)

Notice

2005-05-05T13:24:00.000-05:00

Do not delete the "nofiles" group. Not that I did, but while getting a better understanding of our qmail setup, I noticed that it required it, it doesn't look important, and if it were deleted we would not notice immediately.

SpamAssassin Update

2005-04-29T15:43:00.000-05:00

I noticed while surfing spamassassin that their software had been updated, so I'm getting the latest update now. Normally we get the source, download it to /var/src/tar, untar it, and then run ./configure, ./make, and then ./make install. However, because I followed Bill's Linux qmail toaster, the installation is slightly different. I ran the following cryptic commands instead:

perl -MCPAN -e shell
o conf prerequisites_policy ask
install Mail::SpamAssassin
quit

When it asks about SQL related tests, I told it no. Our whitelist/Bayesian filter uses a flat file that mimics a database, and we're not hardcore enough to need an SQL database for any of that.

Note that until spamd is restarted, 3.0.2 will still be running, but I'm going to wait until a bit later to restart and test it.

modified phpBB2

2005-04-29T10:31:00.000-05:00

Changed phpBB2/login.php per T's request. We'll need to keep this in mind for future upgrades, since replacing login.php with a new version will clobber my change. This is the type of thing I am trying to avoid as much as possible with the boards, but there was no other way to make this required change.

Server Log

2005-04-28T14:44:00.000-05:00



    Order allow,deny
    Allow from all


    Order allow,deny
    Allow from all



  
    DocumentRoot "/www/triviasite.invalid.com"
    ServerName "triviasite.invalid.com"
    ServerName "www.triviasite.invalid.com"
                             
                                    
    DocumentRoot "/www/mail.triviasite.invalid.com"
    ServerName "mail.triviasite.invalid.com"

Added support for new trivia site

2005-04-28T14:25:00.000-05:00

1) ~vpopmail/bin/vadddomain triviasite.invalid.com
2) Created appropriate DNS entries at everydns.net , including MX record, A record, and four CNAME records (for www, mail, pop and smtp subdomains)
3) created mail.triviasite.invalid.com and www.triviasite.invalid.com directories on /www
4) copied all files recursively from /www/mail.example.com to /www/mail.triviasite.com, and ran ./configure so that all options were changed appropriately
5) vlogin plugin for squirrelmail should work the same way, but may need some tweaking.

Now some rights management cleanup..
1) Chowned /www to apache:apache
2) Recursively chowned /www/mail.triviasite.invalid.com with apache:apache
3) Same thing for /www/triviasite.invalid.com

Also I have to update the /opt/apache/conf/httpd.conf, and do more rights management cleanup.

Website update -- Opportunities Page

2005-04-27T09:07:00.000-05:00

Updated the opportunities page on the main website. The four page format has been broken... Several specific job descriptions now appear, linked to off of the main site. This was a good pilot for information we will need to gather/organize for the upcoming site revamp.

We still need to come up with something to do with some of the old directories that are hanging around. We can address that specifically at a later date.

Added to tcp.smtp

2005-04-26T15:34:00.000-05:00

1) Added one China entry to tcp.smtp
#Chinanet
61.187.:deny
2) recompiled: tcprules tcp.smtp.cdb tcp.smtp.tmp < tcp.smtp

Ran rsync to bring failover server up to date

2005-04-25T15:51:00.001-05:00

1) Went to main, verified that there was a test entry in /etc/rsyncd.conf
2) Verified that there were files in the test directory
3) Verified the status of the test directory on the failover
4) ps aux | grep rsync on main to verify that /usr/bin/rsync --daemon is running
(in the future, maybe we should consider killing the daemon on the receiving machine to eliminate the possibility for errors)
5) Ran: failover:/ # rsync -avn --delete main.main::test /home/vpiattelli/Documents/testdel (the 'n' is for dry run)
6) Ran: failover:/opt/rsync # rsync -av --delete main.main::test /home/vpiattelli/Documents/testdel
7) Verified that everything was happening the way I want.
8) Backed up /www to /www_backup on both main and failover. Also checked the [www] entry in /etc/rsyncd.conf
9) Ran: failover:/ # rsync -avn --delete main.main::www /www
10) Ran: failover:/ # rsync -av --delete main.main::www /www
11) Verified that everything was happening the way I want.
12) Double checked [db] entry was setup appropriately on main
13) Backed up db data
14) Ran failover:/ # rsync -av --delete main.main::db /usr/local/mysql/data
15) Backed up mail data
16) Ran failover:/ # rsync -av --delete main.main::mail /home/vpopmail

Static IPs and server updates

2005-04-23T19:23:00.000-05:00

The failover is up and running, with heartbeat disabled and certainly not fully upgraded. But several major goals were accomplished:

1) Failover is connected to Main. Thus we can edit Failover by sshing into Main, and then into lin2. We can also do quick backups via rsynch to make ourselves comfortable even if it's not fully operational.

2) Failover is a static IP with successful internet access. This make configuring certain settings much easier because I can only use DHCP to assign one IP via mac address, due to crappy web interface to the router.
2a) I got the static IP working by making sure that the gateway (192.168.1.1) was explicitly set in the network settings for the external network card.
2b) Static IP continues to work even with router firewall and server firewall running. This is good, because previously I was unable to get it to work with the firewalls running.

3) Heartbeat and rsynch are both off, so nothing crazy can happen. Rsynch has been removed from the crontab on Failover and Heartbeat has been removed from runlevels 3 and 5, so it won't activate on a reboot. We should be able to upgrade and test failover at our leisure, and keep it updated with manual rsynchs so it is ready to go if something happens."

Ripmime upgrade from 1.4.0.3 to 1.4.0.5

2005-04-21T16:47:00.000-05:00

1) Got the latest tar, ftped it to over, moved to /var/src/tar
2) Extracted it to /var/src/ripmime-1.4.0.5
3) Ran make, and make install
4) Seems to work just fine.

Spam cure

2005-04-21T11:03:00.000-05:00

I noticed that some spam has been getting through to spamtrap because the spammer is forging the from address as us, and I have us whitelisted. I was originally concerned that some legitimate email might be dropped, but I haven't found that to be the case, and it's really pretty easy to forge and I don't know how to stop it. So, I'm going to take off that whitelisting but leave in the *.mil whitelisting.

1) edited /etc/mail/spamassassin/local.cf
2) ran "svc -d /service/spamd" (stop the spamassassin daemon)
3) ran "svc -u /service/spamd" (start the spamassassin daemon)
4) Profit

Random AWStats stuff

2005-04-20T14:07:00.000-05:00

1) Ran /usr/local/awstats/wwwroot/cgi-bin/awstats.pl config=blah.invalid.com -build

2) Updated /etc/awstats/awstats.blah.invalid.com.conf so DNSLookup=1 instead of 2, so we can see hosts.

3) Updated crontab with "/usr/local/awstats/wwwroot/cgi-bin/awstats.pl config=blah.invalid.com -update", to run twice a day

Did you know that you can read logs in real time by doing tail -f /var/log/mylog? Pretty cool.

---------------------------------------------------------------------

I think the Alias command isn't working, because AWStats sets up three aliased directories, and I had to make them literal directories in /www/example.com. I also erased everything in /var/lib/awstats and had it rebuilt, so now all the IP addresses are reversed in the display.

To see it, go to www.example.com/cgi-bin/awstats.pl

Hard reset of xinetd

2005-04-18T16:52:00.000-05:00

The chkconfig thing works, but for changes to take effect for something (in our case ftpd), we needed to do the following command to do a hard reset of xinetd:

"kill -USR2 pid" where pid is the pid of xinetd. You can find the pid out by just doing a ps -elf | grep xinetd.

Listing, Enabling, and Disabling services

2005-04-18T14:11:00.001-05:00

Listing, Enabling, and Disabling services

After a bit of research, I finally figured out a simple way to turn xinetd services on and off.

To list services, run the command:

chkconfig --list

To turn a service off (such as cvspserver), run the command:

chkconfig cvspserver off

This won't really have an impact, although it may give us warm fuzzies because the router isn't routing these ports anyways, since we shut them off long ago.

User Accounts deleted
Because we now no longer had a need for them, several user accounts were deleted. They are not listed for security reasons.

Password length was increased to 16 characters.

Turning off services and deleting accounts

2005-04-18T14:11:00.000-05:00

Differentiated blocking: Incoming vs Outgoing

2005-04-18T11:43:00.000-05:00

Here's a quote from http://cbl.abuseat.org, a blocklisting group that spamhaus uses that's relevant to our last experience with overblocking:

"We're getting a lot of reports of spurious blocking caused by sites using the CBL to block authenticated access to smarthosts / outgoing mail servers. THE CBL is only designed to be used on INCOMING mail, i.e. on the hosts that your MX records point to.

If you use the same hosts for incoming mail and smarthosting, then you should always ensure that you exempt authenticated clients from CBL checks, just as you would for dynamic/dialup blocklists."

I'm going to poke around in google groups and see if I can find a newsgroup that can tell me how to block on the smtp level without blocking authenticated users. If any of you can find the answer first I'll give you a cookie.

IPTraf

2005-04-18T11:38:00.000-05:00

IPTraf is a ip traffic monitor that we have available to us, which you run on the command line with just "iptraf". That will pull up the graphical gui. To have it run in the background and generate logs, "iptraf -g -B" should do it. To kill it, do "kill -USR2 pid" where pid is the pid of iptraf.

Upgraded to phpBB-2.0.14

2005-04-18T11:07:00.000-05:00

1) Downloaded changed files only
2) Unzipped 2.0.13_to_2.0.14.zip
3) Uploaded to server
4) Created backup of existing message board scripts
5) Replaced files in live directory with those in the .zip
6) Ran /install/update_to_latest.php
7) Deleted /install directory.
8) Verified configuration
9) Deleted backup

____________________________________

phpBB-2.0.14 Changelog

- Hardened author and keyword search a bit to not allow very server intensive searches

- Fixed full path disclosure in bad word parsing

- Resetting complete userdata array in session code if authentication fails

- Fixed bug in moderator control panel where certain parameters could lead to an "error creating new session" sql error

- Fixed bug in session code where empty page ids could lead to an "error creating new session" sql error

- Fixed html handling in signatures if html is turned off globally

- Fixed install.php problem with PHP5 register_long_arrays option turned off

- Fixed potential issues with styling system

- Added correct class to login_body template file

- Removed file db/oracle.php from package.

- Removed version number from message body page in /admin (if user is not an admin) - mikelbeck

- Fixed case-sensitivity issues in postgres7.php - R45

NTP Daemon: Synchronizing the time

2005-04-14T14:30:00.000-05:00

I went into Yast and turned on the NTP daemon, and told it to start up on boot as well. This should slowly align our system time to the correct time, because apparently making sudden adjustments to the computer time is very bad. So, hopefully in a few hours the server won't be 5 minutes fast.

Edit: Nothing seemed to happen, so I changed the servers it was using because I could find no reference to those servers. I changed it to us.pools.ntp.org, and the date immediately changed to the correct date. But the hardware clock stayed the same. I'm going to see if the hwclock changes slowly, and if not then just set it to the system time and assume nothing terrible will happen.

More things about qmail, including crucial timestamps!

2005-04-13T12:53:00.000-05:00

If you're wonding if someone is getting an email, or if an email is stuck, or if an email is in the middle of sending, here's what you can do:

1) First thing I do is check processes with ps -elf. Qmail launches a qmail-send thread for every email it's in the middle of sending, and you'll be able to see the sender and the recipient. You can run iptraf and see if there's some activity or if it's just hanging dead.

2) If qmail is having trouble contacting someone's mail server for whatever reason, it'll keep retrying for about a week. It doesn't retry every minute, but more like every hour. MTA's go down more than people think, because it's generally invisible what with the retrying. You can check the queue with "qmailctl queue", and see the senders and recipients that have not completed, which will not have the word "done" to the left of them.

3) You can try and force the mail in the queue to send again with qmailctl flush. If you check ps-elf and don't see any sending, then it's probably because it got rejected right away. Time for step 4!

4) Checking the logs. If an MTA is rejecting email, it'll usually respond with a reason which is readable in the logs. /var/qmail/current always has the latest stuff, so check in there.

5) Where the heck are the timestamps? Well, they're in there, just compressed. To get human readable timestamps out of the logs, you have to pipe it through tai64nlocal, like so:

cat /var/log/qmail/current | tai64nlocal

I've made a readlog script in the qmail log directory with just this line in it. Why am I so amazing?

6) Okay, you've flushed and checked the logs and you have no answer or it's cryptic. It's probably the other guy's fault. Now it's time for fun with telnet. Just telnetting to port 25 of whateverdomain.com isn't going to necessarily work though. You've got to find out the mx record for that domain, and then telnet to THAT IP. To find that out, go to dnsstuff.com and on the right hand side to a DNS lookup and change the combo box to "MX", and type in the domain name. That will look up the mail exchanger(s) that go with that domain name. There could be multiple, and you have to look at the priority to see if one they have a cascading failover or a random load balanced setup. Or just one plucky server.
Oh, and if there's no MX records look up the A record, and that's your guy. Almost everyone has MX records though....

7). So do a telnet mxserver.whatever.invalid.com 25 (because it's port 25, not 23) from the server and see what you get. You should get some sort of RFC appropriate response, and you can type in commands like HELO and get a response. You can troubleshoot from there. If it rejects you out of hand, try telnetting from a machine with a different IP address, something at our other office will do, and if you get a different reaction then we probably need to be whitelisted.

Links removed

2005-04-13T11:30:00.000-05:00

Removed those pesky links from the side.

Antivirus out of date continued

2005-04-12T16:14:00.000-05:00

4) Ran make
5) Ran make install
6) Ran freshclam, it appears to be logging every 2 hours now according to /var/log/freshclam.log that the freshclam daemon is running, so that's all good
7) Stopped clamd service with svc -d /services/clamd
8) Started clamd service with svc -u /services/clamd
9) Uh oh.. according to /var/log/clamd/current I'm getting an error over and over again (ERROR: LogFile requires full path.)
10) I kill it with "svc -d /services/clamd"
11) Great, mail won't send if clamd isn't running.
12) I quickly go into /var/src/clamav-.82 and run a make install, and then svc -u /services/clamd
13) Gotta figure out what the error is

Deleted old domains

2005-04-12T12:29:00.000-05:00

I deleted our old testdomains by going to ~vpopmail/domains/bin and

1) ./vdeldomain testdomain1.invalid.com
2) ./vdeldomain testdomain2.invalid.com

This should make mkeeling happy.

Antivirus out of date, freshclam not running

2005-04-11T17:50:00.000-05:00

The antivirus scanner on email was way out of date, and our virusscanner engine is out of date too. I don't think we can automate updating the virusscanner, but virus database updates should be daily. I turned on the freshclam daemon (/etc/init.d/freshclam start), and I went into the runlevel editor and told it to start the freshclam daemon on runlevels 3 and 5.

To get to the runlevel editor, which determines when something boots, either run the graphical version (boooo!) or just type "yast" at the command line, go to System, and then Runlevel Editor. Runlevels 1 and 2 are mostly for debugging and 4 does not exist, 0 is for halting and 6 is for rebooting. Thus if you want something to start when the machine boots normally, check run level 3 and 5.

Also, the freshclam daemon (which updates the database every two hours) does not seem to care if other daemons are running, so you have to be careful that only one is running or else they will all try to update the database every two hours. I saw this happening in the logs.

So, I also got the latest virus engine and updated:

1) downloaded clamav-0.83.tar.gz to /var/src/tar
2) untarred in /var/src with tar -xzvf clamav-0.83
3) cded into ./clamav-0.83 and ran ./configure

TO BE CONTINUED

Adjusted Blocking List

2005-04-08T08:41:00.000-05:00

1. Modified ~vpopmail/etc/tcp.smtp:
changed 68.32-59.:deny

to 68.32-44.:deny
68.46-59.:deny

Bob happens to be on a Comcast account in the 32-59 range.

2. Needs recompile, but I am unsure how to go about that...

Comcast cable modems blocked

2005-04-07T13:53:00.000-05:00

1) Added more to ~vpopmail\etc\tcp.smtp:

#Comcast cable modem space
24.0-23.:deny
67.160-182.:deny
68.32-59.:deny
#68.60.0.0/16 contains business customers
68.61-63:deny
68.81-83.:deny
69.139-142.:deny

2) Aaaaand recompiled: tcprules tcp.smtp.cdb tcp.smtp.tmp < tcp.smtp

Website mod

2005-04-05T16:43:00.000-05:00

1. I removed the summer positoin from the site.

2. Spacing, wording needs to be addressed and repaired...

Messing with netblocks

2005-04-02T22:19:00.000-05:00

I'm adding some more blocks (To OC3 Networks, some of our old inhabitants get an ungodly amount of spam from only them), and I thought I'd put down a little tutorial/refresher about IP Addresses, and what that little slash thing means, and why we care.

First, Spamhaus lists one OC3 netblock as:

72.11.144.0/21 OC3

Okay, so we need to put this entry into our handy tcp.smtp file. Unfortunately, it does not accept this convenient format. Instead, it wants "72.11.x-y.". So, how do we determine what x and y are? The answer lies in the (/21). Breaking down 144 into binary, we get 10010000. The most basic rule when you are assigned a block is, counting from the leftmost bit, all of the bits before and including the (/zth) bit cannot be changed. So, for our example:

72.11. is the first 16 bits, so we count 5 more and see that 10010xxx is what we have to work with in the third octet. The X's can be either 1's or zeros, so to find the full range of the addressed block we set it to all 0's (144) and get x, and then all 1's (151) and get y. We know now that the third octet ranges from 72.11.144.0 to 72.11.151.255 To express this in a way that tcp.smtp can understand, we write 72.11.144-151.

Another quick one: 72.11.152.0/22, would be (72.11.152-155.) Thinking about this for a second, we can see that y is just x + 2^(difference between (/z) and number of bits in the full octet) -1.

Update to SMTP Server blocking

2005-03-29T23:30:00.000-05:00

Based on the advice of a university mail admin, I added the following lines to my /home/vpopmail/etc/tcp.smtp file

#Korea
61.31.:deny
61.37.:deny
61.41.:deny
61.42.:deny
61.43.:deny
61.72.:deny
61.73.:deny
61.74.:deny
61.75.:deny
61.76.:deny
61.77.:deny
61.78.:deny
61.79.:deny
61.80.:deny
61.81.:deny
61.82.:deny
61.83.:deny
61.84.:deny
61.85.:deny
210.181.:deny
210.206.:deny
210.221.:deny
210.222.:deny
211.168.:deny
211.171.:deny
211.172.:deny
61.97-111.:deny
61.248-255.:deny
203.226-231.:deny
210.109-115.:deny
210.121-127.:deny
211.33-61.:deny
211.104-109.:deny
211.174-179.:deny
211.189-255.:deny
218.36-39.:deny
218.48-54.:deny
218.144-159.:deny
218.232-239.:deny
219.248-255.:deny
220.64-95.:deny
221.138-168.:deny
222.96-122.:deny
222.232-239.:deny

#Japan cable modems
219.0-63.:deny

#Brazil
200.128-255.:deny

and then compiled it with

tcprules tcp.smtp.cdb tcp.smtp.tmp < tcp.smtp

For more info on the previous syntax, google "tcprules man". (Sorry this is so terse, it barfed while trying to post three times and I got sick of rewriting it)

configured phpBB2 for increased security

2005-03-28T11:54:00.000-05:00

1) Disabled HTML
2) Disabled remote avatars
3) Removed version number
4) Changed forums from "private [hidden]" to "registered [hidden]"
5) Added user ranks

Server Log Template Change

2005-03-28T10:02:00.000-05:00

1. Updated slog for new look and feel

Trusted Networks

2005-03-24T15:31:00.000-05:00

1) Added the line "trusted_networks 192.168.1/24" to /etc/mail/spamassassin/local.cf because spam started to come in whose scores were being subtracted from by the tag ALL_TRUSTED, when it was clearly coming from untrusted networks. Restarted qmail (with qmailctl) and spamd (with supervise, the command is svc -d /services/spamd and then svc -t /services/spamd, not entirely sure about those flags but you can view the qmailctl script to see what the appropriate ones are, it uses supervise as well)
2) Might be nice to make a spamctl, based on qmailctl

Finished phpBB Installation

2005-03-23T16:11:00.000-05:00

1. Configured for communication with local SMTP server
2. Configured for admin approval on all new accounts
3. Created SBIR Category
4. Hid SBIR Category from non-members
5. Signed up for phpBB mailing list

Began phpBB Installation

2005-03-21T13:17:00.000-05:00

1. Downloaded version 2.0.13 from http://www.phpBB.com.
2. Uploaded to /var/src/tar/
3. Untarred
4. mv'ed to /www/invalid.com/phpBB2
5. Set up database connectivity (new user, new db)
6. Created admin account

Updated Squirrelmail

2005-03-18T11:31:00.000-05:00

1) wgetted version 1.4.4 of squirrelmail into /var/src/tar
1a) wgetting didn't seem to work, did the ole download and ftp thing
2) Extracted to /var/src/squirrelmail-1.4.4
3) Copied /var/src/squirrelmail-1.4.4 contents to /www/mail.blah.invalid.com
4) Checked it out, no problems noted

Updating AWStats

2005-03-18T03:49:00.000-05:00

1) Edited /etc/awstats/blah.blah.conf
1a) Changed Logfile to = /opt/apache/logs/access_log
1b) Checked thatLogFormat=1 because 1 is combined and because under httpd.conf, the log line has the word "combined" after it.
1c) Changed www.blah.com to just blah.com in the SiteDomain line
1d) Pages and pages of optional settings, all left to default

2) Recursively chowned /usr/local/awstats/wwwroot (something awstats put up) as apache:apache

3) Ran /usr/local/awstats/wwwroot/cgi-bin/awstats.pl config=blah.invalid.com -build
3a) It got angry at me, I created /var/lib/awstats and chowned it apache:apache, which seemed to make it happy, it spit out a ton of qualified records

4) Copied /usr/local/awstats/wwwroot/cgi-bin to /www/cgi-bin, where our other cgi stuff is. Didn't see it before I moved it.

5) Switched some stuff that I changed to blah.invalid.com back to www.blah.invalid.com, rebuilt, and I'm getting results. Looks like I'm missing some icons, will mess with that and make sure logs are outputting correctly later.

Site updated

2005-03-17T16:33:00.000-05:00

- The new CSS version of the current site has gone live.

- The old version has been saved in /www/blah/old and is still accesible via tha man site.

We should probably make a decision about archiving old data/versions