Registration

Let's start by registering our own preferences on distribution, as well as our experience level with any distro (preferred or otherwise). If you have any "I refuse to have anything to do with" opinions, note those too. Avoid explaining why at this point; let's just survey the field.

• BenScott - Prefer a RHEL clone like CentOS. Most experienced with Red Hat Linux, Fedora, and Red Hat Enterprise Linux clones. I've tried SuSE, Mandrake, and Debian in the past. I'm willing to work with just about anything.
• BruceDawson - Suggest either RHEL (maybe we can get a company in Westford to donate a copy). I also have experience running Ubuntu servers. I do not recommend a plain Debian server installation - too much customization is required.
• BillMcGonigle - If we can get a RHEL license, great (make sure that includes support since RHEL support is less community-based). If not, CentOS would avoid costs we can't afford - how's it's track record on maintenance releases? Fedora Core might be worth looking at since it tracks new features the fastest, if we want this to be the 'shining city' server. My server is currently RH9 - it works just fine but it's the old dusty city. I run FC2-4 at several client sites without any distro-specific problems and the community support is great. Anyway, the goals should be to minimise cost, sysadmin requirements, and roadblocks, in that order.
• ToddWarfield - Suggest RHEL or RHEL clone (CentOS) as that is what I am most familiar with. Concern would be throwing something 'cool' on it (Ubuntu) that none of the admins have worked with enough.

Requirements

The following items outline some of the requirements of the distribution. These exist in light of this system being managed by a (probably) disjoint set of people.

• Automatic updates (ala yum, up2date, ...) Especially security updates!
• Experience within our community of sysadmin volunteers.

Recommended packages, policies and procedures

• sudo

• All admins have their own account on the system.
• Disallow root access, except via sudo.
• Disallow sudo access. Yes, this make things more difficult, but traceability is needed when there are multiple admins. Note: I could be coaxed off this requirement if sudo would fire up a capture program (like script) when 'sudo ' is used.
  • Some things that require shell redirection don't work without this - however those can be put into a script and run 'sudo script'. But then the script is fungable after the run, so what's been gained is worth debating. -- BillMcGonigle - 08 Feb 2006
• SSH - Require public key authentication, require entries in AllowedUsers in sshd_config. Inconvenient for adding new accounts, but the number of accounts will be very low and we don't have time to deal with getting cracked.
• iptables - unless there is some other level of firewalling available to us.
  • even if there is a hardware firewall, don't trust it. To expound, only allow incoming access on the minimum number of ports to get us going. We should restrict ssh access to a limited number of IP's to avoid being DDOS'ed with ssh scans. -- BillMcGonigle - 09 Feb 2006
  • Allowed Ports From Anywhere
    • 25/tcp
    • 80/tcp
    • 443/tcp
    • 53/udp
  • Allowed IP's for port 22 ssh
    • 217.160.248.65 -- BillMcGonigle - 09 Feb 2006
  • Allowed Ports for our backup DNS, currenly LINUX.CODEMETA.COM (199.125.76.10)
    • 53/tcp