Had to upgrade an old mailman server to Ubuntu Precise and decided to use nginx with fastcgi.

After looking around at various howto's and tutorial sites, tried a few with poor results. The closest to working behavior was mailman listinfo and admin pages loading but nothing beyond those.

Turns out the fcgiwrap program has an old feature to work around some initial shortcomings in nginx. Then nginx implemented fastcgi_split_path_info to address the need. Since version 1.0.2 fcgiwrap has both it's old behavior and a mechanism to use nginx's solution available.

Here is the relevant snippet from the fcgiwrap man page:

  To  disable  PATH_INFO mangling, set up your web server 
  to pass SCRIPT_FILENAME, which should contain the complete 
  path to the script. Then PATH_INFO will not be modified.

After reviewing the regexes being bandied about and the docs on fastcgi_split_path_info and fcgiwrap handling of PATH_INFO and setting the mailman base directory, here is a working nginx config section:

  root /usr/lib/cgi-bin;

  location / {
    rewrite ^ /mailman/listinfo permanent;
  }

  location /mailman {
    fastcgi_split_path_info (^/mailman/[^/]*)(.*)$;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_param PATH_INFO $fastcgi_path_info;
    include /etc/nginx/fastcgi_params;
    fastcgi_pass  unix:/var/run/fcgiwrap.socket;
  }

This handles requests to http://server.your.domain/mailman. This also avoids setting /usr/lib as the web server document root as in the howtoforge tutorial.

For Ubuntu the mailman base directory was changed in /etc/mailman/mm_cfg.py:

  DEFAULT_URL_PATTERN = 'https://%s/mailman/'

Hope someone finds this helpful alongside the other noise on this issue.

We are finally moving to dynamic routing on our network edge and a more traditional layout.

Here is what we are moving to:

   ProviderA     ProviderB
    |             |
    |   -----------
    |   |
  Firewall-----DMZ
    |  
    | 
  Other ASU Networks

Now for the fun stuff. We are using Devil-Linux which provides a recent version of Quagga. ProviderA switched on full routes for us and we had a complete Internet table within a few minutes on a 2GHz quad core Xeon. It could have been faster, wasn't really paying attention.

Here is what was reported for the full BGP IPv4 table:

  gbfw3# sh ip ro sum 
  Route Source         Routes               FIB                  
  kernel               5                    5                    
  connected            9                    9                    
  ebgp                 419061               419061               
  ibgp                 0                    0                    
  ------
  Totals               419075               419075

Quagga memory use:

  gbfw3# sh mem
  Memory statistics for zebra:
  System allocator statistics:
    Total heap allocated:  102 MiB
  ...
  Memory statistics for bgpd:
  System allocator statistics:
    Total heap allocated:  119 MiB

Some BGP memory detail (for our test link):

  gbfw3# sh bgp mem 
  774465 RIB nodes, using 47 MiB of memory
  418923 BGP routes, using 13 MiB of memory
  1 Static routes, using 32 bytes of memory
  1 Adj-Out entries, using 20 bytes of memory
  68594 BGP attributes, using 2412 KiB of memory
  11269 BGP extra attributes, using 792 KiB of memory
  60412 BGP AS-PATH entries, using 708 KiB of memory
  60468 BGP AS-PATH segments, using 709 KiB of memory
  1575 BGP community entries, using 25 KiB of memory
  6 BGP community entries, using 96 bytes of memory
  2 peers, using 5048 bytes of memory
  23 hash tables, using 460 bytes of memory
  130605 hash buckets, using 1531 KiB of memory

From top:

   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
  7587 quagga    20   0  131m 121m 1220 S    0  6.0   4:15.48 bgpd
  7580 quagga    20   0  159m 103m  972 S    0  5.1   0:33.11 zebra

For comparison, here are entries from a 2 peer VM we used while testing BGP with only a couple of prefixes:

   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
  1602 quagga    20   0 67964 2336  900 S  0.0  0.5   0:03.12 bgpd
  1081 quagga    20   0 11708 1532  936 S  0.0  0.3   0:00.02 zebra

  Memory statistics for zebra:
  System allocator statistics:
    Total heap allocated:  395 KiB

  Memory statistics for bgpd:
    System allocator statistics:
    Total heap allocated:  1059 KiB

Follow up post when we add ProviderB, and again when we advertise our IPv6 block.

Update, provider B will only provide us with a default route, so we don't get to see the RAM usage for 2 sets of full routes.