1. 29 Aug, 2016 1 commit
    • Leigh Stoller's avatar
      Various fixes to deactivate/reactivate code, mostly to deal with not · bf77e242
      Leigh Stoller authored
      wanting to call setgroups cause it is so slow. also refactor the code to
      chown/chgrp user dot files so we can call it from reactivate.
      
      Refactor the code that bumps user/project activity and calls exports
      setup so that we can call it from reactivate.
      
      When deleting a ZFS home/proj directory, do the ZFS rename and then
      set the mountpoint=none, no need to have it mounted.
      bf77e242
  2. 25 Aug, 2016 5 commits
  3. 23 Aug, 2016 8 commits
  4. 22 Aug, 2016 1 commit
  5. 19 Aug, 2016 3 commits
  6. 18 Aug, 2016 5 commits
    • David Johnson's avatar
    • David Johnson's avatar
    • David Johnson's avatar
      Best effort to decrease dhclient latency on Ubuntu 16. · 5bc94e54
      David Johnson authored
      (AFAIK, nothing has changed about dhclient, etc... I just noticed on the
      Emulab d820s (which have BCM5720s, tg3 driver), the driver takes
      anywhere from 7-9 seconds to simply init the card and autoneg with the
      switch (I've seen worse times, too, i.e. 19 and 29 seconds!).)
      
      dhclient is happy to start sending requests on interfaces that have no
      carrier (gee, did it ever seem like a good idea to make that behavior
      optional???).  Thus, if we get stuck with a control net NIC that has a
      horribly long init/autoneg time, dhclient is far into its backoff
      strategy on the control net, when it doesn't need to be!  In addition to
      slow media negotiation, there are STP auto things that can further delay
      the forwarding state of a switch port (like the ProCurve "auto-edge"
      port setting that causes the switch to wait 3 seconds after media
      negotiation for a BPDU).  So we have to be a little smarter about
      bringing up the control net via DHCP.
      
      So to combat these possible scenarios, we try two main things.
      
      First, we modify findcnet to wait for one of two things to be true
      before we start dhclient at all (or until a 6-second timeout is
      reached): 1) if we have a previous control net device in
      /var/lib/dhcp/dhclient.leases, we wait for that to come up; or 2) if we
      don't have a previous control net device (i.e. first boot of an image),
      we wait for at least one device to obtain carrier.  We could increase
      the 6-second timeout, but we'll wait on that for now; this should be
      good for now.
      
      Second, we set initial-delay and initial-interval both to 3 seconds in
      dhclient.conf ; hopefully this will give STP protection schemes a chance
      to have gotten things straight by the time dhclient makes its first
      retransmit.
      
      I tried adding a forced 'ifconfig <X> up' to the udev interface handler
      script, just to try to kick the device into autoneg mode ASAP, but of
      course that didn't help anything.
      
      I cannot improve on this unless we move to a split, managed dhclient
      scheme, where we actually run a dhclient for each interface, and control
      the backoff time much more tightly.  For now, I don't want to do either
      of these things.
      5bc94e54
    • Mike Hibler's avatar
      Yet another new version. · 5b941237
      Mike Hibler authored
      5b941237
    • Robert Ricci's avatar
      Fix mail sending when $mailfrom is not set · 27ff9193
      Robert Ricci authored
      27ff9193
  7. 17 Aug, 2016 7 commits
    • Mike Hibler's avatar
      Updates for soon-to-be FreeBSD 11.0. · becc02e5
      Mike Hibler authored
      becc02e5
    • David Johnson's avatar
    • David Johnson's avatar
      Update the Centos 7 passwd files more, for systemd this time. · d2e3d707
      David Johnson authored
      This time systemd-tmpfiles-setup.service was broken ; just reinstalled
      systemd (fortunately the same version) and harvested the new master files.
      d2e3d707
    • David Johnson's avatar
      Add Centos 7-specific passwd files. · f8d130c0
      David Johnson authored
      polkitd was missing, and this causes systemctl to hang for ~30 seconds
      when doing some of its operations (and of coure polkitd does not run).
      I fixed this by doing 'yum reinstall polkitd' and saving new masters in
      prepare.
      f8d130c0
    • David Johnson's avatar
      ec37e347
    • David Johnson's avatar
    • David Johnson's avatar
      Use the last resort systemd swap strategy: wrap the systemd-fstab-generator. · 828e7acd
      David Johnson authored
      As noted in a previous commit, systemd generators run at boot, with the
      rootfs mounted read-only, prior to systemd reading any unit files on
      disk.  The systemd-fstab-generator reads /etc/fstab and generates units
      for any devices in there, including swap devices.  Thus, the only way to
      ensure our swap device fixing happens correctly (and we have to do this
      in case the image was loaded from an old MFS that might write a swap
      device with /dev/hda or whatever into /etc/fstab), and doesn't race with
      systemd, is to preempt it.
      
      So now our generator runs the systemd generator each boot, but it
      post-processes the auto-generated unit files, removing them if any of
      those devices was 1) an Emulab auto-generated swap device, and 2) it
      does not exist.
      
      Moreover, if there is *no* swap device in /etc/fstab, we hunt down the
      canonical Emulab swap partition on the root disk, and mkswap it, and
      generate a unit for it.  Of course, we don't use the system template (it
      is an m4 file in the src dist, so we can't), but hopefully the template
      won't change much --- and it's basic.
      
      We now only mkswap devices if they don't appear as swap devs via blkid.
      
      To clean up old Emulab systemd images, do these steps:
      
        $ systemctl disable emulab-fstab-fixup.service
        $ make client-install
        $ rm -f /usr/local/etc/emulab/initscripts/emulab-systemd-swaps
      
      I think that will do it.  Worked for me on Ubuntu 16 and Centos 7.
      
      Here's the comments from the generator for posterity:
      
        This is a systemd generator that wraps systemd-fstab-generator.
      
        First, we always run the system generator; and any swap file units
        it generates are modified to contain a
        Before=emulab-fstab.fixup.service dependency to ensure the fixup
        script never races with legitimate systemd unit targets.
      
        If it has already run on an Emulab node (and if the second-stage
        fixup script (emulab-fstab-fixup.service) has also run), we don't
        run it again; we just run the system fstab generator directly,
        modify the generated swap unit files to run before the fixup script.
      
        Otherwise, on first boot of an Emulab image, we run the system
        generator and let it generate swap units for any swap devices that
        were in /etc/fstab.  We then check all the auto-Emulab-added swap
        device entries in /etc/fstab, and if that device does not exist, we
        remove the auto-generated unit files/symlinks that correspond to it
        (they are in $1).  We cannot edit /etc/fstab ourselves because we're
        run prior to remount-/-rw; so we make a copy of it in /run/emulab
        and move the copy to /etc/fstab in emulab-fstab-fixup.service ---
        the second part of our solution (the fixup service).
      
        NB: we do not remove user-added swap devices, even if they are
        invalid!
      
        We check to see if each auto-Emulab-added swap device that was in
        /etc/fstab is currently a valid swap device (i.e., that it shows up
        via blkid with a TYPE="swap").  If it is valid, we *do not* run
        mkswap to create it!  If it is not currently a valid swap device,
        but if the partition is marked as a Linux swap partition, we will
        run mkswap on it to ensure it is valid by the time systemd runs
        swapon on it.  If we *did* plan to run mkswap, that can be prevented
        by creating the
        /etc/emulab/emulab_systemd_fstab_generator_never_mkswap file.  This
        gives the user the ability to create a disk image where swap
        partitions are not created/wiped on first boot of the image.  I
        can't see a use case for this, but it's easy to do.
      
        If there is a swap partition on the device containing the root
        partition, and if it is not already in /etc/fstab, we try to add a
        unit ourselves for that swap partition.  We do it in the new style,
        too, by using its UUID, in this case.
      
        When scanning /etc/fstab to find auto-Emulab-added devices, we look
        for a comment above a line containing a swap device, and the comment
        must match the regexp /^#.*the following.* added by / .  Then if the
        line below the comment refers to an invalid swap device, we remove
        the unit files that correspond to the device.  Otherwise
      828e7acd
  8. 16 Aug, 2016 1 commit
  9. 15 Aug, 2016 1 commit
  10. 14 Aug, 2016 2 commits
  11. 12 Aug, 2016 2 commits
  12. 11 Aug, 2016 4 commits