[vox-tech] postfix and apache

[Rick Moen]

Quoting Charles McLaughlin (cmclaughlin at ucdavis.edu):
> Cylar Z wrote:

> >I downloaded, compiled, and installed PostFix
> >sucessfully. It seems to be able to send and receive
> >mail via the "mail" command at the prompt.
> 
> I'm no expert on mailservers, but I have to wonder - doesn't your distro 
> have a postfix package?  Why not use rpm or apt-get?

Second the motion, strongly.  I recently appended a comment about these
matters to a _Linux Gazette_ article I was editing for the upcoming
September 2005 issue.  (The author, like Matt, had sought out and
compiled a source tarball from the upstream author, in circumstances
where it's not obvious that he should need to.)


  [1] Rick Moen comments:  While it's useful and worthwhile to know
  about a program's "upstream" development site, where (among other
  things) the author's latest source code can be downloaded, there are a
  few disadvantages that should be noted, (and some alternative locations
  that should be usually be preferred, instead, if such are findable):  

  1. Absent extraordinary measures on your part, your Linux distribution's
  package-tracking system won't know about the program's presence on your
  system.  Therefore, it won't know to avoid installing conflicting
  programs, removing libraries it depends on, etc.  

  2. You won't get any tweaks and enhancements that may be normal (or
  necessary!) for applications on your Linux distribution — unless
  you yourself implement them.  You won't get security patches, either, 
  except those written by the upstream author.

  3. Along those same lines, the desirable version to compile and run may
  well not be the author's latest release:  Sometimes, authors are trying
  out new concepts, and improvements & old bugs fixed are outweighed by
  misfeatures & new bugs introduced.

  4. As a person downloading the upstream author's source code directly, 
  you have to personally assume the burden of verifying that the tarball
  really is the author's work, and not that of (e.g.) a network intruder
  who cracked the download ftp site substituted a trojaned version.
  Although this concern applies mostly to software designed to run with
  elevated privilege, it's not a strictly academic risk:  Linux-relevant 
  codebases that have been (briefly) trojaned in this fashion, in recent
  years, on the upstream author's download sites, include  Wietse Venema's
  TCP Wrappers (tcpd/libwrap), the util-linux package, sendmail, OpenSSH,
  and the Linux kernel (CVS gateway's archive, only).  Unless you are 
  prepared to meaningfully verify the author's cryptographic signature 
  -- if any -- on that tarball, you risk sabotaging your system's security.

  All of the above are problems normally addressed (and the burden of
  solving them, shouldered) by Linux distributions' package maintainers,
  so that you won't have to.  It's to your advantage to take advantage of 
  that effort, if feasible.   The memory of when a thousand Linux sysadmins,
  circa 1993, would need to do all of that work 999-times redundantly, is 
  still fresh to us old-timers:  We call those the Bad Old Days, given
  that _today_ one expert package maintainer can instead do that task 
  _for_ a thousand sysadmins.  And yes, sometimes there's nothing
  like such a package available, and you have no reasonable alternative
  but to grab upstream source tarballs -- but the disadvantages
  justify some pains to search for suitable packages, instead.

  Depending on your distribution, you may find that there are update
  packages available directly from the distribution's package updating
  utilities, or from ancillary, semi-official package archives (e.g., 
  the Fedora Extras and "dag" repositories for Fedora/RH and similar
  distributions), or, failing that, third-party packages maintained by
  reputable outside parties, e.g., some of the Debian-and-compatible 
  repositories registered at the apt-get.org and backports.org sites.
  Although those are certainly not unfailingly better than tarballs, 
  I would say they're generally so.

  The smaller, less popular, and less dependency-ridden a package is, the
  more you might be tempted to use an upstream source tarball.  For
  example, I use locally compiled versions of the Leafnode pre-2.0
  betas to run my server's local NNTP newsgroups, because release-version 
  packages simply lack that functionality altogether.  On the other hand,
  that package's one dependency, the Perl PCRE library, I satisfy from my
  distribution's official packages, for all the reasons stated above.