Last modified 7 years ago Last modified on 09/12/12 09:57:07

DevOps Weekly Meeting | September, 11 2012

Time & Location: 11am-12:30am in LHL164


2012-09-11 Agenda

  • Agenda bash
  • Research Computing Day 2012
  • Virtual Machines
    • Defining secure container
      • further discussion of solutions for controlling traffic
        • if we use distinct IP net with the same problem exists though so still need to control traffic with ebtables/iptables/routing table combo
    • Public IP to third party -- routing across subnets
  • Research storage pilot
    • pending: jpr, mhanby: tear down f5 test (vm, nfs3, and test data)
    • access to smb from 164.111 net.
    • todo
      • how to define interfaces into a lab network
      • dealing with large files on the research storage
      • fold nas-03 & nas-04 into storage access
  • Backup scripts for apps failing due to account deactivation
    • update
    • pending: contact IT to update software downloads to allow fac/staff to see student license; avoid burdensome reclassification at Mathworks.
    • todo: matlab pool from outside of Cheaha



The discussion focused on how to manage the host iptables/ebtables and coordinate the changes for manual NAT creations with SNAT/DNAT and the automatic rules created by libvirt. We discussed how puppet, fwbuilder, or eventually openvswitch might be used to managed the fabric. We generally agreed that we are in a better position currently to leverage puppet given that fwbuilder doesn't have an active management component, though it does have libfwbuilder. We will eventually need to have our management span the cloud-* hosts and that would likely lead to openvswitch since it can migrate descriptions across systems.

The reason for introducing custom SNAT/DNAT NATing rules is because the default NAT mechanism in libvirt relies on the MASQUERADE feature of iptables which doesn't work with interface aliases. MASQUERADE needs explicit distinct hardware devices, either through real hardware, VLANs, or virtual NIC. The SNAT/DNAT approach allows us to overlay multiple IPs on one interface with simple device aliases by adding the rewrite rules explicitly.

We will also introduce a distinct IP network to simplify deny rules so we don't need to create exceptions that need to span all the cloud-* hosts.

2012-09-11 devops libvirt, openvswitch, fwbuilder, NAT, puppet