GitLab

Can do ext[234] or ufs.

with disk images being corrupted.

correct (non-xen) kernel.

booting XEN VM, let the library function deal with that, since
there is now code in there to watch a dead control network and
retry.

network to see if we can catch when a node is never going to boot
cause XEN created a broken control vif; tear down the VM and try
again, which seems to solve the problem most of the time.

for elabinelab (multicast, apod).

say to do that instead of bridge mode. Sadly, the xen script that does
this is broken and so here is our version.

add an extra ssh pub key to elabman so that the user can log into
new boss, since when setting up a rack all existing accounts are
deleted. Store this key as ~/.ssh/elabinelab.pub.

A closer inspection of the 'fedora' case that I had been using revealed
that a few changes needed to be made for the CentOS 6 environment.  This
is loosely based on the fedora15 case, but stripped down and cleaned up
some.

instead.

The template configurations in the new ntpd subdir also address the
recent NTP amplification attacks that have been going on recently.

NTP configuration is controlled by a few defs-* variables:

NTPSERVER: boss|ops|fs|<external-server-name-or-IP>
  Default: "ops"
  Normally, one of boss, ops, or fs is designated as a local NTP server
  but this can be set to a fully qualified name of some other machine.
  If NTPSERVER is set to an external server, then boss/ops/fs are made
  clients of that server just as any testbed node is.

EXTERNAL_NTPSERVER[1-4]: <external-server-name-or-IP>
  Default: "[0-3].pool.ntp.org"
  If NTPSERVER is one of boss/ops/fs, then these values are used as the
  upstream servers for the local server. These can be changed to four of
  your favorite NTP servers.

NTPDRIFTFILE: <path>
  Default: "/var/db/ntp.drift"
  If NTPSERVER is one of boss/ops/fs, then this is the name of the drift
  file for the local server.

It has been dead for a long time and I am tired of seeing the message.

Also fix for xl toolstack error; teardown called with no XENBUS path,
so no way to find the bridge name. But we know what it is, so add it
to the env so that vif-bridge does not croak.

We were using pygrub to suck the kernel and ramdisk out before
booting the guest, but doing that makes it impossible for for
the guest to change its kernel and reboot.

Other minor fixes.

1. The backend process that starts the XEN vm (xl/xm) was not happy
   with the signal mask settings. By pass that for the vnodeboot call
   so that xl/xm sees a clean mask. The sympton was processes getting
   left behind.

2. Watch for a XEN container being rebooted from inside, by waiting a
   little bit to see if comes back on its own. We used to fold right
   away, but now keep running.

As of FreeBSD 9, the race condition in mountd has been addressed.
We automatically (based on the OS running) add the option to mountd (-S)
as part of ops-install. There is also a configuration variable, NFSRACY,
that we auto-detect and set in elabinelab setup. For regular installs,
you need to set this manually in the defs-* file. Note that the setting
in the defs file does not affect very much. It is passed to the client-side
which uses it in one copy function (used as a fall back for getting the
topology file).

There are still a couple of places in the Emulab code where handling
the race condition is hardwired into the code (most notably, imagezip).
These remain.

Note that we don't actually have an install target for FreeNAS, so this
file mostly serves as a reminder that we must overwrite the FreeBSD version
of rc.kname on freenas.

Move the command execution and storage-related stuff from
libvnode to libfreenas. The interface and vlan stuff is still in
libvnode since it is currently the only one that uses it.

We don't want to alloc/dealloc them on vnode setup.

Right now, libfreenas.pm is largely a duplication of libvnode_freenas.
The two need to be refactored.

We need to know if a blockstore is persistent so we can avoid blindly
doing a mkfs on those!