Server infrastructure is periodically updated to provide clients with the latest software and provide us an opportunity to implement hardware/architecture changes.  The Fourth Generation was introduced March 2007, which is beyond the target lifecycle of 24 months.  I would love to hear your input on what you want on the new server family.  Initial filesystem structure will be based from a mix of RHEL 5.3 and Fedora Core 10 packages with software upgrades as deemed necessary.  Beneath the OS there are a few other hardware and architectural changes to improve performance and propel the phenomenal reliability to new levels.

My observations and notes only represent a small slice of deficiencies.  I want your help in identifying current short-comings to be addressed in the Fifth Generation. The most successful, forward-thinking businesses are those that are driven by its clients.  The Fifth Generation aims to be the most ambitious iteration yet, so let’s set the bar high and give me a challenge.  Here are some brainstorming questions:

  • What software versions would you like to see?  Ruby 1.9 and Python 2.6 are planned.
  • Any layout changes, e.g. webmail locations, behaviors, subdomains, addon domains, etc?  Bear in mind these changes are more difficult to execute and possibly more disruptive.
  • If you could change one thing about apis, what would it be?
  • Ways to improve user experience?  How can we facilitate daily operations for you?  For example, is SpamAssassin inaccurate with tagging spam?  How would you like spam management change on the new family?

Questions are very open-ended, because any form of feedback is invaluable at this stage.  Brainstorming is a stage when tangents run amok and somewhere from that chaos [deceptively] good ideas emerge.   Software version requests are posted within the wiki.  Head on over to the forums and let’s hear not only what you need, but more importantly, what you want.  The Fifth Generation build is set to begin in May.

Discussion link
List of planned changes
Send me your ideas!

Designing the next generation server

7 thoughts on “Designing the next generation server

  • April 2, 2009 at 4:39 pm UTC
    Permalink

    Hey Matt,

    Thanks for letting us give some input! This is one of the many reasons why Apis is one of the best hosts around.

    I just have one query for now, and I apologize if this can already be done: site-wide spamassassin settings in one go, i.e. setting filters and scores etc. for every user.

  • April 3, 2009 at 11:34 am UTC
    Permalink

    It is definitely something that I can either work into the next generation or integrate immediately. Accounts currently have access to global maildrop filtering through /etc/maildroprc. Account-wide rules would be implemented as a custom patch to SpamAssassin.

  • April 6, 2009 at 6:00 am UTC
    Permalink

    Two suggestions, although I’m not sure about the feasibility of them both.

    * Global repository of popular rubygems (and PEAR/python eggs?) as they can take a bit of space. I stripped 100MB of documentation from the gems installed on my site for example, and I don’t have a necessarily large gem collection either.
    * SSH login without using username@domain.org username. The only reason for this is because scp thinks username#domain.org is invalid and the command-line syntax doesn’t accommodate @’s. I concede there’s probably a good workaround for this and I’m a bit of a shell amateur.

    • April 10, 2009 at 7:32 pm UTC
      Permalink

      Global repository:
      PEAR is only possible by Apache running outside the filesystem jail. CGI applications would require a shared mount for each account that enrolls in such a service. I could strip the documentation and source from gem installations initiated through the control panel — that's a good suggestion that I can implement before the Fifth Generation is rolled out.

      Dropping @domain:
      I sense this will become the most requested change by May… 🙂 Implementing a facility that allows logins without @domain for the primary user that also jails entails ditching Ensim's proprietary NSS and PAM modules. Possible, planned down the road, but basically too intensive to add to the work queue right now.

      You can substitute '@' with '#'. Some clients, FTP come to mind, have difficulty parsing the URI if '@' is present more than once. A sufficiently newer OpenSSH may fix the warning with scp, but I would recommend rsync instead. More flexible in its options, accepts '#' in the login, plus faster in my experience. rsync -a foo#foobar.com@foobar.com:/home/abc or you could setup a function…

      function remsync { ARGS=($@) ; LEN=${#ARGS[@]} ; FILES=${ARGS[@]:0:$(($LEN-1))} ; DIR=${ARGS[@]:$(($LEN-1))} ; rsync -a $FILES foo#foobar.com@foobar.com:"$DIR" ; }

      (Well that sucks… no code or pre tag support with the comment system. At least it's only an ugly one-liner.)

      Need to copy something over? remsync /my/files/a /home
      rsync will recursively copy directory contents with the -a flag. You could add flag support with getopts to arbitrarily supply arguments such as -a…

  • April 7, 2009 at 11:52 am UTC
    Permalink

    Matt: great to hear it’s feasible. It would be very useful for at least one of the people I referred you to. 🙂

  • Pingback:New: Global SpamAssassin Preferences (and some software updates) | Apis Networks Community Updates

Comments are closed.