GNHLUG> Org Web>InternetServer>ServerDistro (revision r1.4)EditAttach
When it comes to our InternetServer, there will be some unavoidable discussion on choice of distro, even if we avoid a prolonged debate. This page gives that discussion a home.

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.

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. [note from Bill - 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]
  • 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.
Edit | Attach | Watch | Print version | History: r22 | r6 < r5 < r4 < r3 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r4 - 2006-02-08 - BillMcGonigle
 

All content is Copyright © 1999-2024 by, and the property of, the contributing authors.
Questions, comments, or concerns? Contact GNHLUG.
All use of this site subject to our Legal Notice (includes Terms of Service).