![\includegraphics[height=3in,width=5in]{condiments.eps}](img1.png)
Michael C. Richardson
Sandelman Software Works Inc.
mcr@sandelman.ottawa.on.ca
April 28, 2005
The CoSE work site is a collaboration system intended to aide government, non-government, and private-sector developers to work together easier on projects of interested to the Government of Canada. The work site will contain only unclassified materials, but with distributions ranging from unlimited to limited to specified parties. This document explains how the use of role-based access controls will be used to control distribution of project information.
As part of this description, it explains the data flow architecture (where data will be stored), how the system can be expanded to meet demand, and how the initial system(s) will be deployed.
A gForge installation was installed for use as a pilot of the CoSE Worksite Initiative.
The system was installed in such a fashion that it could start small, and easily grow to make full use of the capabilities of the hardware provided.
The initial (small) installation was done by the gForgeGroup, such that they would be willing to provide ongoing support for the system.
The large boxes represent physical hardware. The small internal boxes represent virtual systems -- i.e. IBM Logical Partitions (LPARs). The LPARs each have their own installation of SuSE Linux.
Each LPAR has one or two virtual ethernet adapters (using an inter-LPAR VLAN), which is bridged by the Virtual I/O server to a physical ethernet adapter. Each LPAR also has a virtual SCSI adapter, which communicates with the Virtual I/O server.
The Virtual I/O server is a dedicated logical partition running a specialized operating system based on AIX. It has no network connectivity itself. It uses AIX Logical Volume Management to take SCSI disks, raid-5 them, and export the resulting logical volume to the Linux machines as SCSI targets.
The two physical machines (the front end, and the backend) are connected via a cross-over cable. It links the two back-haul network VLANs, connecting the front and back end systems. The front-end systems also have unique IP addresses (one required per logical partition). The back-end systems are also interfaced to the internet as well, as they directly provide certain file-intensive critical services.
The private network between the two machines is implemented by a cross-over gigabit-ethernet cable. The numbering for the private network is taken from RFC1918 private address spaces. There is not access from the back-haul network (not even via NAT) to the Internet.
The nameing system for the machines is things that can be placed on potatoes. (i.e. french fries, poutine, baked potatos, mashed potatoes, etc.). The naming scheme was invented during a meal. The word ``-press'' is appended to indicate that this is where things are made.
The ketchup system runs the following services. These should be accessible to any IP address on the Internet.
A minimum of disk will be used, containing operating system and configuration files only.
The ketchup system will communicate on the back-haul network using the following outgoing ports.
The vinegar system is almost identical in service profile to ketchup. It will accessible to Government of Canada users only, restricted by IP address at the firewall. ketchup and vinegar will receive different allocations of CPU, guaranteeing a certain level of service to gc.ca users, independant of load due to non-gc.ca users.
Role based access control, stored in the user database will determine different levels of access.
A slightly different Look+Feel would be appropriate to distinguish the two user interfaces. A seperate SSL certificate will be required for this system.
The vinegar system will communicate on the back-haul network using the following outgoing ports.
The chive system will be the database server. It runs postgres on port 5432. It has sshd for administrative access. It does not connect to the Internet, only the back-haul network. It sends audit logs to mayo.
The chive system will run an LDAP server on port 389/636.
The chive system runs the primary Domain Name Service for the CoSE worksite. The DNS is, in most cases, taken from the database.
The cayenne system is used by CoSE administrators. It has a full SuSE Linux installation, including compilers. It contains all source code necessary to rebuild the CoSE system(s).
The cayenne system has access to all machines via the back-haul network, and may NFS mount home disk space from butter. It is accessible via SSH from the outside, via public-key methods only. The cayenne system is currently being prototyped as the system salt.cose.gc.ca.
The cayenne system may provide an IPsec gateway for administrators to access the back-haul network remotely.
No system critical functions should be on cayenne. The CoSE worksite should continue to operate with the cayenne system powered down.
The mayo system is the audit server. It collects logs from all other logical systems. It performs no public functions.
Should local backups be done, they may be done on the mayo system.
On the back-haul interface:
The butter system is the file server. (Nmemonic: It contains all the ``fat'')
It contains all CVS (Concurrent Version System) and SVN (Subversion) files/database. It holds all published files from projects.
It holds user home directories, which contain certain settings and keys. Published files from projects are served by virtual download hosts running on ketchup and vinegar.
CVS/SVN access is via restricted (SSH public key, protocol 2-only) login to the butter system, using a chroot'ed, and forced-command environment. Both CVS and SVN can be very disk intensive when performing operations.
In addition, SVN provides for an http-based WebDAV interface to the repository. It remains to be determined if this will run on butter or on ketchup and vinegar.
On the public interface:
On the back-haul interface:
Prior to full configuration of ibmcose59 and ibmcose60 physical hardware with appropriate logical partitioning, an unpartitioned system (ibmcose58) was configured for use by gForgeGroup.
The system, entitled ``salt'' was installed with a PowerPC SuSE Enterprise Linux installation. Email was configured using postfix, and SSH access was provided to gForgeGroup personnel. A configuration of gForge was installed onto the /cose partition of the system by gForgeGroup, using the name ``salt.cose.gc.ca''.
Shortly after satisfactory configuration of the gForge installation, the LPAR configurations were available. As ibmcose58 was slated for upgrade to 4-CPUs, another LPAR on ibmcose59 was prepared, and the ``salt'' machine was replicated onto that LPAR. This occured on March 23, 2005.
At the time of this writing, the ``salt'' LPAR continues to operate on its own. It is planned that a transition as follows will be done:
At each step, the CoSE site will be down for a matter of minutes, and will return unchanged after the movement of the component.
An expert in the Common Look and Feel (CLF) took the stock CoSE templates and adapted them to contain the GC.CA Common Look and Feel.
This is done by having the CLF as the default style for the CoSE site. A single additional style remains available (the ``OSX'' style), in the case that some administrative menus were not translated properly.
The CoSE site itself is accessible only via privacy enhanced HTTPS protocol. A redirect page at the insecure HTTP port offers visitors the choice of English or French. The selection is used to initialize the CoSE web server with either the English or French versions of the interface.
Additional languages are also supported, and once users login, they will receive their preferred language.
The CoSE web site is not accessible unless a user has logged in. This is a standard feature of gForge. However, any visitor may create an account. Among the standard options in gForge, is the option to permit accounts to be created only by the administrator, however if that option is chosen, there is not yet an interface for the administrator to do that.
All accounts created must be verified by use of an email account, at which point the account is considered active. Accounts may also be suspended by the administrator. A non-standard modification was made to gForge such that new accounts are created in the ``suspended'' state. An administrator must activate the new account. The feedback to the user that this has occured is substandard at present.
Dog food is sold to the owners who buy it, not to the dogs who have to eat it. "Eating your own dog food" is a metaphor for a programmer who uses the system he or she is working on. Is it yet functional enough for real work? Would you trust it not to crash and lose your data? Does it have rough edges that scour your hand every time you use a particular feature? Would you use it yourself by choice? 1
The first task that was done when the gForge code was installed was to check it into the gForge 3 system that was built by Richard Lessard (the tricycle system). It was used until such time as the salt system was moved to the ibmcose59 system, at which point the cose.gc.ca zone was also moved, and the CVS for the CoSE project was moved to salt.
This is a critical part of the effort: each new system must be brought up using the previous iteration of the system, and eventually must host itself.
The OPA system will be integrated into CoSE. This will be done by installing OPA onto a new LPAR, giving it the appropriate web server and database that it is used to. The new LPAR will not be Internet accessible.
Access to the web server running on this will be provided via an addition to CoSE. The CoSE machines will proxy the request to the OPA machine. This will permit common authentication mechanisms to be used (OPA has no authentication for proponents), and for the common look and feel to be used.
This work is not yet complete.
Backups are provided by archival of data to a provided NFS server (``orange''). This system is in turn backed up by the Technology Innovation Lab (within Shared Product and Service Development of ITSB) to tape.
Internally, a backup system called Amanda2 was installed on to the ``butter'' LPAR.
The client packet was installed onto each LPAR. Access to the client backup daemon on each other LPAR is restricted to occuring only over the ``back-haul'' network.
The backup server uses the ``chg-disk'' tape controller, which simulates a series of tapes using disk space located on the orange NFS-server.
Backups of the database on the salt installation of gForge
At the time of this writing, the CoSE worksite is active. It has 20 registered users, and 5 projects created.