GitLab

the virtual interface name given the tmcc-returned ifconfig info.  tmcc
just returns the physical interface underlying a virtual interface, so it
is no good for setting up, e.g., the gated config.

. Force reboot, or at least sleep, when attempt to run  rc.reboot gets fork: Resource temporarily unavailable.
. In rc.ifc generated script, check both netsh and ipconfig IP addresses for 0.0.0.0 .

Sometimes a NIC would claim to configure, but not take an IP address.  Disable/re-enable the interface when that happens.

Zap gated setup.

Use cygrunsrv -i on sshd to "allow the service to interact with the desktop."
Now that the sshd daemon has a desktop session context that is inherited by
the client shell, remote home directories can work.  They start with a blank
Windows mount context, but once a single Samba connection is made during
login, it enables all UNC //machine/path mounts to work.  Hence the home
directories are now CygWin mount points (no longer symlinks) to UNC paths, set
up by rc.mounts and then shared through CygWin to all of the user logins.

Get rid of the previous horrible (and fragile) hack to set up an auto-login by
the swapin user which then automatically started a user sshd on port 2222.

tmcd.c - Arrange for tmcd to provide the public key data when a special argument is
given as "tmcc accounts pubkeys".

rc.accounts - Due to permissions problems with remote-mounted authorized_keys
files, sshd_config now uses "AuthorizedKeysFile /sshkeys/%u/authorized_keys",
which is where rc.accounts puts the public key data.

Since root, Administrator, and even SYSTEM can be locked out by permissions on
NT, WINDOWS() variant logic to set ownership and modes on authorized_keys
files had to be added to rc.accounts.  There is also a bug in the sshd
"privilege separation" setreuid() dance that requires the authorized_keys
files to be owned by SYSTEM (or be mode 644, which is slightly worse.)

cygwinxp/liblocsetup.pm - Pay attention to the users' shell preferences in
generating /etc/passwd.  Make warnings more uniform.

autologin of the swap-in user, and a user sshd on port 2222.

Overview of simply firewall setup.

Experimentor specifies in their ns file:

     set fw [new Firewall $ns]
     $fw style <open|closed|basic>

to set up an "open" ("allow any"), "closed" ("deny any"), or "basic"
(allow ICMP and ssh) firewall.  "basic is the default.  Additional rules
can be added with:

     $fw add-rule <IPFW format rule>
     $fw add-numbered-rule <1-50000> <IPFW format rule>

where the former implicitly numbers rules such that the firewall processes
them in the order given in the NS file.  The latter allows explicit
specification of the numbering.  Currently the rules are fixed strings,
there is no variable substitution.  There is also no syntax checking done
on the rules at parse time.

We allocate an extra node to the experiment to serve as a firewall.
Currently that node runs FreeBSD and uses IPFW.  In the initial configuration,
all other nodes in the experiment will just be setup with a default route
that points to the firewall node.  So all outbound traffic will pass through
it.  Inbound traffic will still travel straight to the node.  This should
prevent nodes from accidentally initiating attacks on the outside world.
Long term we will of course enforce the firewall on all traffic, that should
not have any effect on the NS syntax above.

When a node boots, there will be an rc.firewall script that checks to see
if there is a firewall for the experiment and if so, which node it is.
This is done with the TMCD "firewallinfo" command which returns:

      TYPE=none

      TYPE=remote FWIP=N.N.N.N

      TYPE=<fwtype> STYLE=<fwstyle> IN_IF=<macaddr> OUT_IF=<macaddr>
      RULENO=<num> RULE="<ipfw command string>"
      RULENO=...
      ...

In the case of no firewall we get back TYPE=none, and we continue as normal.
Otherwise, there are two types of replies, one for a node that is being
firewalled (TYPE=remote) and one for a node that is a firewall
(TYPE=<fwtype> + RULES).

In the TYPE=remote case, the firewall node indicated by FWIP.  This is
the address we use for the default route.

For TYPE=<fwtype>, we are the firewall, and we get STYLE and IN_IF/OUT_IF
info.  Here TYPE indicates whether we should use ipfw or whatever.
For now it is always ipfw.  IN_IF and OUT_IF may someday indicate the
interfaces to use for the internal and external connections, right now
both will indicate the control net interface.  So, after ensuring that
the ipfw modules is loaded, we grab the provided RULE info, which includes
both per-experiment and default rules, and setup ipfw.

Issues to resolve:
       - synchronization: how to ensure firewall comes up first
       - how to better implement the firewalling
         (i.e., without the cooperation of the nodes)
       - support the equiv of linkdelays (on-node firewalling)?
       - allow firewalls within experiments?
         (ie., on experimental interfaces)
       - dynamic changing of firewall rules via events?
       - how to show firewall state in various web pages