Linux as a general purpose shell server?

The University I work for has offered a UNIX (secure-) shell service for its students and staff for over 15 years now. The servers have so far been AIX (Power/PPC), OSF1/Digital Unix/Tru64 UNIX (alpha) and Solaris (sparc64).They’ve also been mostly top-of-the-line (=expensive) boxes so they can handle hundreds of simultaneous users without problems. The exotic hardware and OS also makes it more secure, since script-kiddies tend to use more common hardware and OS’s.

Now we are in the process of phasing out the last remaining publicly available Tru64 server (ES40/4x667MHz, 5GB RAM), and possibly with a x86-64 server running Linux (Ubuntu 8.04). The reason why Linux has not been an option before is that some people claim it still can’t handle the load of ~1000 users reading their email (pine/alpine/mutt) while chatting with irssi or whatnot. Also the security problems have been brought up. It’s possibly a lot easier to break into Linux than Solaris, because Linux is more common and easy to get (although there is Opensolaris now..).

What I’d like to know is that are there people already running Linux on similar purpose, and how does it perform? What measures can be taken against the security threats (preferably something that doesn’t involve building a custom kernel)? What else should be taken into account to make it scale better?

The x86 hardware is at least a lot cheaper. Eight-core blade with 64GB of RAM is less than 8kEUR.. but could it handle 700 users like the ES40 does with ease?

About these ads

10 Responses to “Linux as a general purpose shell server?”

  1. Ryan Says:

    My university runs all-purpose shell servers which are commonly used by our computer science students. I suppose it has at most 200-300 users on it at peak, since that’s about the size of the department; but the users are often running fairly intensive tasks (compilation, stress-testing, etc). We’ve got a linux-x86 server and a Solaris server, but the Linux one is far more popular due to greater familiarity with its user-space tools.

  2. sharms Says:

    Yes, it can handle it. If users generally run a limited set of apps, all of them will share memory because of the shared libraries, and most of the memory will go to IO cache. The ssh connections themselves are not very stressful and a cheap server can handle over 1000 pretty easy.

    The hardest part is locking it down, I know they added chroot for scp, but you would want to do something similar to freebsd’s jail and only give them a small piece of the puzzle.

  3. Johan Says:

    In the department where I work, there’s a linux shell server for general use (dual xeon, 4 gigs ram). This is on a smaller scale (usually around 30 simultaneous users), but it works well: up 101 days, 19:23, 28 users, load average: 0.22, 0.20, 0.18

    For security, you may want to look at SELinux. And enforce tight ssh passwords.

  4. Michael B. Trausch Says:

    Unless I was doing something that really required Linux to be on the bare hardware and not a VM of one sort or another, I would probably use FreeBSD on the server. IMHO, it’s fantastic for servers because of the kernel and base userland software being a single unit and centrally managed. Also, the jail functionality is very lightweight, and means that you can give users with special requirements the ability to have their own constrained environment with multiple users (and a root user).

    Also, FFS2’s fast filesystem snapshots are *very* useful on a server for multiple purposes. FreeBSD can do boot-up fsck in the background using a snapshot, which is very cool, and you can have multiple snapshots of FFS2 volumes. If you’re going to be working with extremely large amounts of data, FreeBSD also includes Sun Microsystem’s ZFS, which might be useful.

    In terms of handling lots and lots of stuff, yes, Linux is certainly capable of that—any of the open UNIX-like systems ought to do so quite easily, actually. It just depends on what sorts of software you’re providing, what the requirements will be.

    For things like password policy enforcement, if you’re using local accounts you can tell PAM to require password changes every so often, require a certain number of classes in passwords, and require that people not change their passwords very frequently. The same can be done on a network with an already-existing Kerberos authentication setup, of course.

  5. Michael B. Trausch Says:

    Oh, and perhaps a not-so-obvious point to think about: Unless you trust all of your users, do remember to restrict access to utilities. The C compiler probably doesn’t need to be invoked by someone that only needs access to the machine for checking their email, for example, but is definitely required for someone who’s building software for installation on the machine, obviously. If you don’t do such things already, I’d start by printing a list of executables in $PATH on the system, configured as it will be for production use, and then marking up that list with the names of groups that should be able to use the software. On Linux, there is getfacl/setfacl that can be used to provide more flexible ACLs than traditional UNIX permissions; FreeBSD supports ACLs, too.

    It’s better (in this case) to start out being too restrictive, and have to wedge things open a bit after being placed in production, than to start out too loose and have a server which you have to treat as compromised on your hands. :)

  6. tjaalton Says:

    Thanks for your comments so far! Couple of things I forgot to mention in the post:
    – we do enforce strong passwords, and linuxes use ldap/krb5
    – we also strip suid-bits from various programs that are installed by default, and change some other permissions so that users can’t get to them

    Ryan: that’s nice to hear. What kind of hardware do you run it on?

    sharms: memory is not the issue :) Our current servers have 5GB / 16GB, and this one would have 64GB, but also huge apps that people would be able to run (Comsol, Matlab etc).

    Johan: we have close to 200 public workstations (accessable remotely via the GP servers) that have similar specs, and some of them have 20-30 users, so I know it can handle that load :)

    Michael: Using FreeBSD would mean yet-another platform to maintain, while using what the workstations already have means that the software stack would be identical and less of a maintenance burden. We already get snapshots for free because the $HOME is on NFS (v3 now, v4+krb5 in the future), and the system will be installed on “disks” behind SAN.

    I asked Kees Cook on IRC about the security, and it’s likely that we’ll use SELinux to harden it, because we already have RHEL servers with it so it’s familiar to us.

  7. Tiago Faria Says:

    Just another +1 for SELinux and, IMHO, grsecurity.

  8. sejeff Says:

    Don’t run ubuntu, run Fedora or CentOS (preferably CentOS) and enable SELinux in enforcing mode. That will stop a huge number of local attacks cold.

    There was a fairly recent /proc suid vulnerability in the Linux kernel that allowed privilege escalation for local users on every distro except for Fedora and Redhat with SELinux in enforcing targetted mode.

    You need proactive security, not reactive security.

  9. rawsausage Says:

    Given the facts that
    – Linux kernel project policy is obscurity over security (fixing security bugs silently – while distribution projects can not track what to backport)
    – Such box is a high profile target – anyone interested CAN find a remotely exploitable kernel bug from the kernel.org git with a few hours of work
    – You don’t want to be rebooting that box often
    no matter what you do, you’re screwed with Linux if you REALLY cared about security. Tbh I would pick any “real” Unix over it if I was you.

  10. black tea Says:

    The other day, while I was at work, my cousin stole my iphone and tested to see if
    it can survive a twenty five foot drop, just so she can be a youtube sensation.
    My apple ipad is now destroyed and she has 83 views.

    I know this is totally off topic but I had to share it with someone!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Follow

Get every new post delivered to your Inbox.

%d bloggers like this: