Lixivial

var exclusionList = new List<string>(new string[] { "projects-403", 
								 "projects-547", 
								 "projects-561", 
								 "projects-562", 
								 "projects-961", 
								 "projects-645", 
								 "projects-897", 
								 "projects-643", 
								 "projects-517",
								 "projects-518",

Lixivial

namespace Tools
{
    using System.IO
    using Perforce.P4;

    public class PerforceCopy
    {
        private static void Copy()
        {
            const string serverString   = "10.10.0.151:1666";

Lixivial

Database schema where applicable.

I'd like to discuss this to get a sense of how you guys interpret relationships between data. I'm particularly curious about the following relationships specifically (please forgive me if I'm misusing terms; I'm trying to keep the terms consistent with what I recall you mentioning), but the more schema the merrier here:

• Realms -> Clients
• Institutions -> Realms -- particularly in how I seem to recall this being at a yearly level, but I get the sense you have some clients with multiple "cycle runs" a year.
• Applicants -> Realms
• Applications -> Realms
• Applications -> Applicants

Integration needs

This is specifically regarding client's security requirements of data transmission and storage compliance.

Lixivial

Code migration and deployment procedures

Outlined below is how code is migrated from branches to trunk with flagged notes outlining where the target 
environments actually are.

It also outlines various scenarios, and base term definitions can be found below the diagram.

Diagram                                                       
                                                     
       +--------------------------------+                                

Lixivial

SA Auth Environment
  
The purpose of this environment is to take internal directory services and expose them to constituent
environments in a secure and scalable way. 

On the internal side (designated SA LAN), we have our domain controller forest. This is represented by 
two domain controllers at the moment whose sync process is not outlined in this diagram.

For the external auth environment, we have n-number of backend authentication storage providers. Backend
providers could include:

Lixivial

iSMS Production Diagram

This diagram is a fairly straightforward load balanced web tier with a clustered database tier scenario. Since our usage expectations can be modeled and predicted there is little need for a distinct hardware load balancer resident between web and database tiers. I think we can generally trust the SQL Server controller node(s) to sufficiently route db traffic to the correct partitioned cluster. Since elasticity is not a primary concern, session coherence will be managed with sticky sesssions on the load balancers. The prevailing requirement on the web, database (and likely domain controller) servers is that it'll be running Windows. The mail relays may be Linux-based running sendmail or postfix.

All connections to public-facing infrastructure -- whether they be over HTTPS or LDAPS -- are restricted to Scholarship America public IP addresses. This can be achieved either at each constituent endpoint (web and backup domain controller) or directly via the VPN box. Our eapp environment cur

Lixivial

Basic document management deployment.

eapp and isms both use inforouter for document management facilities; the front-ends for these are scaled 
independent of the UI front-ends. The only bottleneck and single point of failure is the metadata db, 
which by Inforouter's definition must be a single database.

The inforouter fs cluster is still slightly undefined at the moment. I'm hoping we can use any standard filesystem 
providers. If we were to use s3, we may need an arbitration subsystem to act as a gatekeeper and translate inforouter calls
into HTTP REST calls.

Lixivial

Flow of email through Amazon            _________________                 ________________________
                                       /                 \               /                        \
 ___________________________           |  regional relay |               |       postini failover |
/                           \      +--->     primary.mx. <---+--smtp-+---> outbounds6.obsmtp.com. <-----------------+
|                     web-1 |      |   |                 |   |           |                        |                 |
|       primary.apache.web. |      |   \_________________/   |           \________________________/                 |
|   ________       _______  |      |    _________________    |            ____________________________________      |    ___________
|  /        \     /       \ |      |   /                 \   |           /                                    \     |   /           \
|  |  php   |     |       | |      |   |  regional relay |   |           |                Amazon SES fai

Lixivial

Unhandled guidelines:

• DG 1-6 (HSTS headers need to be investigated)
• DG 2-2
• DG 2-3
• DG 2-8 (username should be considered sensitive)
• DG 3-1 (need to expose this in a general sense)
• DG 3-7 (need to review this in code)
• DG 3-9 (need to acquire access to their blacklist and then check submitted passwords against it)
• DG 3-12 (need to confirm this with Jodi)

Lixivial

#!/bin/bash
# map_sync.sh - Jesse M. Pearson
# contact: jesall@gmail.com
#          or
#          irc.quakenet.org/#prae.nexuiz
#
# Description:
# A script to synchronise the latest files across a set of servers (server_list.txt).
# Its intended usage is through a cron task, though manually running it
# one-time via CLI would work, too.