View OctopusLinqpadYay.cs
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",
View PerforceCopy.cs
namespace Tools
{
using System.IO
using Perforce.P4;
public class PerforceCopy
{
private static void Copy()
{
const string serverString = "10.10.0.151:1666";
View srs-questions.md

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.

View code_deployments
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
+--------------------------------+
View auth_env.txt
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:
View isms_production_diagram.txt
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
View basic_deployment_
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.
View email.txt
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
View gist:3867838

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)
View map_sync.sh
#!/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.