I restored all of quark's backup sets onto quarkprime as a full-blown test of Amanda. Everything worked, and I'm now doing the mundane stuff like running rsync and restoring the Postgres databases.
The FreeBSD Security team reported today a vulernability with the procfs filesystem. This affects both 4-RELEASE and 5-RELEASE. I have successfully patched quarkprime and backup, and quark awaits a good time to reboot to get it patched.
I've installed a trial instance of Bugzilla on quark and quarkprime for general use by the department.
I'm using my chat server/client as a trial product in Bugzilla, and all appears to be working.
I've upgraded PHP on quarkprime from 4.3.4 to 4.3.8 to try to fix some library problems wrt ppckernel. The experience was long, tiring, and frought with peril. Avoid it at all costs.
The steps I did:
1. Uninstall everything. Yes, everything. Apache, PHP, and mod_*. Apache and PHP seem to dump core if you don't do this, although this might be specific to us. (We also were upgrading Perl.)
2. Build Apache w/ mod_ssl support.
3. Build all the modules you uninstalled.
4. Build lang/php4.
5. This is the tricky part to realize. Some genius decided to split PHP into a "base" part and an "extensions" part. There's no reason I can think of that you would want only a base installation, and the ease of upgrading modules is far offset by the sheer tomfoolery that needs to be done to get to that point. And how many times do you need to build a new PHP module anyways? So, build lang/php4-extensions. If you mess up the config the first time, realize that it also uses the unannounced "new and improved" way of configuring ports, where not even a complete rebuild of the ports tree can remove a configuration. Run "make config" if you need to restart the configuration process.
6. If you haven't done so yet, you'll find yourself saying "WTF?" at this step. Because the ports doesn't configure the path to the extensions directory, so you have to add it yourself to etc/php.ini. Find extension_dir, and put in something like this:
/usr/local/lib/php/
You should be done at this point, and deserving of a break.
I've installed strace on quark and quarkprime for debugging purposes.
I've upgraded rsync on quark and quarkprime in response to a buffer overflow regarding the way rsync handles paths.
I've taken quarkprime offline to try to get it as close to quark's setup as possible. I blew everything away, booted off a rescue CD, and started restoring off backup's dumps of quark. Hopefully it'll be done sometime today.
I've added a third NIC to quarkprime, allowing a crossover connection between quarkprime and image for monthly image backups.
It should be noted that the NICs in quarkprime are numbered starting from the bottom; that is, the bottom NIC is xl0, the next one up is xl1, and the top one is xl2.
I've setup a DNS slave on quarkprime.
I copied all of /var/db/namedb, /usr/local/etc/namedb, and all the rndc keys to quarkprime. I then changed both forward and reverse CS zones to slave, and pointed the master to quark.
I added a second 3com NIC to quarkprime, so that it can have its own dedicated link to quark. It's only a 100Mbps link, but I don't know if quarkprime's disks can saturate that anyways.
I fixed the booting problem we were having with the quarkprime. Apparently the BIOS will try to boot off a hard drive connected to the integrated SCSI controller and completely ignore anything bootable from the Mylex RAID array. When I removed the 4GB SCSI hard drive, the system started booting from the RAID array without a hitch.
I just finished installing FreeBSD on Quarkprime (yes, I know it's 6:30 AM, but I've been on an odd sleep schedule lately). Anyways...it's installed but in a rather crippled state as I haven't done anything to it yet. You can ssh to it (159.28.230.9) and login as root, but that's about it.
Some things to note:
I enabled the RAID BIOS as Skylar mentioned before the install, and I didn't really know what kind of bootloader to install so I chose 'none', but it would not boot unelss I disabled the RAID BIOS. If I disabled it, it beeps whenever the machine boots. Is this ok?
Also, will we want to revert Qaurkprime and Image's IP address back to their original ones? It seems like we'd just have to edit a few files and everything would be ok.
The upgrade to perl 5.8.4 for suidexec wasn't as easy I thought it would be. None of the modules were moved from the 5.8.2 directories to 5.8.4. A nice fix, however, was to move 5.8.2 directories away, and symlink the new 5.8.4 directories into place. At least ports build now.
I've fixed a security hole in the way DNS recursion is implemented in BIND9.
I added an acl rule for CS:
acl cs {
127.0.0.1;
192.168.0.0/24;
159.28.230.0/24;
159.28.135.0/24;
};
In the options section, I added this line:
allow-recursion { cs; };
I've patched quark and quarkprime against this vulnerability.
I've upgraded quark to Apache 1.3.31 in response to several security vulnerabilities discovered in 1.3.29.
Because MIMEDefang is a milter and MailScanner needs two queues and two runs of sendmail, there's a significant (2x) performance hit if we use MIMEDefang with sendmail. I've disabled MIMEDefang, and mail acceptance rate went up dramatically on quarkprime. It takes longer to deliver, but we get no more of those 4xx temporary failure messages from sendmail when we run out of MIMEDefang slaves.
I have MailScanner configured and working on quarkprime. This seems to be a nice way to integrate ClamAV and SpamAssassin into one pacakage, and add a few other checks in the process.
Basically, MS works like this:
1. One sendmail process listens on port 25, and puts messages into an incoming queue.
2. MS scans this queue, picks up messages, and runs all its checks on them.
3. Once done checking the messages, MS puts the checked/disinfected/flagged messages into another queue, where another sendmail process picks them up and performs local delivery.
The biggest disadvantage I can see is that this increases the overhead of mail checking, but quark's specs puts us at a significant advantage in this respect. According to the MS docs, a P-II running all sorts of mail checks (SpamAssassin, MIMEDefang, Pyzor, ClamAV, etc., etc., etc.) can process 5,000 a day, which is more than what quark processes, so we should be good in that respect.
Here's the gory details for the setup of MS:
1. Install it from ports.
2. Edit MailScanner.conf. This is extremely well documented, so it's nothing complicated. The big things to notice are that it can call ClamAV and SpamAssassin, so there's no need for the milters.
3. Comment out the milters in $HOSTNAME.mc, so we don't double-check messages. Stop sendmail.
4. Copy mailscanner.sh.sample and mta.sh.sample to mailscanner.sh and mta.sh respectively. Make whatever changes are necessary.
5. Make /var/spool/{mqueue.in,MailScanner/incoming,quarantine}. You might also have to touch /usr/local/etc/MailScanner/rules/bounce.rules.
6. Fire up MailScanner and sendmail using mailscanner.sh and mta.sh. You should be good to go at this point.
I've been testing out freebsd-update on quarkprime. Looks like it works well (or at least no problems).
I've enabled ClamAV on quarkprime. It's a free, open-source anti-virus package. It seems to be working beautifully.
I made the following changes:
1. I enabled the Syslog option in clamav.conf so it will log to mail.
2. I added the following line to quarkprime's mc file:
INPUT_MAIL_FILTER(clmilter,S=local:/var/run/clamav/clmilter.sock,F=, T=S:4m;R:4mE)dnl
3. I added these lines to rc.conf:
clamav_enable="YES"
clamav_milter_enable="YES"
clamav_milter_flags="-q -lo /var/run/clamav/clmilter.sock"
Following my guide on here, I generated valid TLS certs for quarkprime. We should be ready to do this for quark.
I'm running portupgrade on quarkprime now. Test your stuff out to make sure it all works.
I've excluded the following sets of packages from the upgrade:
bsdpan*
postgresql*
mysql*
apache*
sendmail*
These can be upgraded manually if need be.
I've enabled full HTT support on quarkprime, in preparation for enabling it on quark. Previously, the logical processor only handled hardware interrupts, but now it can handle processes as well. This should improve performance marginally.
In the migration to the new quark, MIMEDefang stopped passing mail through SpamAssassin.
To solve that problem, I setup a separate milter for SpamAssassin. I installed the spamass-milter package, and added this line to quark.cs.earlham.edu.mc:
INPUT_MAIL_FILTER(`spamassassin', `S=local:/var/run/spamass-milter.sock, F=, T=C:15m;S:4m;R:4m;E:10m')
After restarting sendmail, everything was working fine.
(Check to make sure it starts on boot-up)
I have upgraded quarkprime to Apache 1.3.29. Squirrelmail, PHP, PHP CGI, and mod_ssl all seem to be working fine.
This upgrade was done per this CVE vulernability report.