(background: i set up "Small Business Internet Gateways" for a living. right now i have about 20 clients, ranging from mom-n-pop size businesses to 25 person design engineering companies.)
regarding your two part article, it's a pretty good compendium, but i have a few comments:
a) the average small business doesn't need or want squid. there is very little temporal or spatial locality to the objects that "internal" surfers are accessing. KISS -- keep it simple and stupid, unless you like fixing stuff 24x7. squid is a memory, disk, and CPU hog -- not what you need on your gateway.
b) in part 1 you recommend against sendmail as being "too complicated". then in part 2 you go ahead and install BIND? google "djbdns" and get BIND out of the picture. i too used to wrestle with BIND, spending hours with cricket's book in my lap. then i discovered djbdns and now i wish i could get back all that time i spent with BIND. for your average small business with an internal domain, djbdns is sooooo much easier to install and configure. it works, it's secure, adding new records is trivial, end of story.
c) work in stages and with security in mind. configure the firewall first, default DENY, and then start adding services. install squid before setting up the firewall? that's the wrong order. install tripwire (or one of it's equivalents) so you can see when you get rooted. :^)
d) the first step should be to delete all the RPMs of stuff you DON'T need. this will 1) make updating easier, 2) improve security, and 3) prevent people from mucking with things they don't understand. (case in point... clients who email me and say "i noticed that i can't seem to run a graphical desktop on the gateway console, and i want to reconfigure the firewall to allow my son to IM with his friends from my office desk.")
e) backups. backups. backups. you are insane if you think that a "small business" is going to accept a few days of downtime while you rebuild their server and website from scratch. instead of installing squid as the first task (totally unneeded, as noted above), install a backup system that will allow you to recover the ENTIRE box in 8 hours or less. disks fail, plan for it or you'll have unhappy clients. for this reason i suggest coming up with a standard config that fits 90% of your clients needs. then, the last 10% you have to work with, but keeping commonality across boxen makes your like a lot easier.
f) monitoring traffic looks sexy to the client. but totally extraneous for you. instead, monitor CPU utilization, disk space, and process creation rate. these are the things that ultimately get you in trouble. example: it should not be a surprise when the gateway runs out of disk space in 10 months, 'cause /var/spool/mail is full of crap. use MRTG to plot disk usage from day one. after a month or two, it will not be difficult to extrapolate when the disks are going to max out. and this can be a GREAT early warning indicator that your ftpd config has been compromised -- all of sudden disk usage soars as the latest Matrix movie mpegs are hosted on your box. another example: notice that /usr is growing? find the log file that is located on /usr and move it NOW. process creation rate is another great indicator that something is amiss. when a busy box goes from 1-5 per sec to 50 per sec it's time to look into what the problem is.
g) externals: have a backup mail server (MX) record configured for your client, so if their server takes a dump their email (which = MONEY) continues to get deposited somewhere that they can get to it. and, have an external DNS record configured so that you don't have to do zone transfers across the client gateway.
hope all that leads to a more disciplined approach.