Thu Aug 26 13:24:31 EDT 2010 Organizational thoughts: The scope of a "networking" group is a bit vast. People who are interested, able, and willing to contribute or to learn in one area should be able to engage without wasting a lot of time on areas in which they have little to no interest or aptitude. Whether it's a "task" or a "project" or a "subproject" or whatever, I don't think everyone needs to be involved with every aspect of every part of what we've lumped together under "networking." Policy thoughts: Regarding the network policy, as of the draft I last looked at (it may have changed since then) but it seems the language precludes our being able to run security audits/scans/pen tests of our production network. We need to be able to do these things, and so we need the policy to be able to support that need. In that vein, I think the way to do that is to say "you can't do [these things] unless you notify [who] [when] and [how]". I accept the possibility of some bikeshedding for the stuff in brackets, but maybe tacking something like this onto the part forbidding network scans etc would work: "except when planned in advance as part of a bona fide security test, announced 48 hours in advance to the group through the mailing list routinely used for group discussion, or through written notice (paper or electronically) to the officers. In the event of an emergency, the 48 hour notication may be waived by agreement of a) at least two officers and b) any other member in good standing working on the network infrastructure." Personal druthers: Now, as for my own interests, what I'd like to have and be able to do, minimally, and what I'm seeking support for in terms of hardware space, power connections, physical network connections, and network OS configurations: I. A piece of hardware or two, on the project network, on which I will manage a) a Xen or KVM host. This system needn't stay up 24/7, but I do want to be able to b) power it on remotely and I'd like the host and the guests to be able to c) reach other services on the project network. For the time being, I'll be content for the guest OSes to c) receive IP address assignments via DHCP for the internal, project network. Any fixed-address or static IP needs would be handled later through change-management. On these DHCP provided IP addresses, I'd like d) to be able to reach at least some other project network devices/services/hosts, such as the OpenFiler box via ssh, CIFS, NFS etc. and the LDAP server. Depending on what is going on with the guest systems hosted by this box, it might stay up for extended periods, but any switch to "I expect this to be up continuously" would be a managed change handled down-the-road. Guests developed on this system may stay on this system, or might be migrated to a different hosting environment (eg, ESX) as determined later, depending on whether and when they graduate from being "toys" to providing some service of ongoing use. II. A port on an external IP that is forwarded to an ssh daemon. III. A remove power management device. IV. An ssh daemon running on some Unix-like operating system, which can be reached from outside and which can, in turn reach, through the project network, a) the Xen/KVM host in Ia and b) a power management device (Ib/III) and c) the Openfiler box or any successor storage medium. Currently, the 1U box known as "dalek" fulfils some combination of these goals. It has an external IP running an ssh daemon, thus satisfying IIa. It runs a Xen domO, thus satisfying I. There seem to be a number of options for reasonably-priced power-management switches. My intention is to buy one, to satisfy Ib/III/IVb. Right now I can ssh straight into dalek. I don't need that connection to be so direct. An ssh bastion host running on ESX, for instance, would be OK, so long as it was dual-homed (virtually, I suppose) with the ssh daemon able to listen for connections from the outside network (through a port forward) and able to originate a connection to (at least some part of) the internal project network. I have also considered bringing in a Linksys NSLU2 "slug" I have running Debian for this purpose (although its ability to handle ssh is a bit . . . sluggish).