I managed to get Mush to compile on modern Linux machines.  It is now available on ALL of our Linux servers.

     We have a new server available for your use but this one is in the yellow-snow.net domain.  The full server name is julinux.yellow-snow.net.  If you use this server, e-mail you send will by default by username@yellow-snow.net.  E-mail to this address will also come to your INBOX.

     This server is a new Linux distribution called JULinux but it is only barely a distribution as it is essentially the Mate spin of Ubuntu configured to look like Windows with very nice artwork.  The software is all 100% Ubuntu so it has the stability, security, and is current like Ubuntu.

     The KDE implementation is broken in as much as the logout does not work so I would ask that you avoid using KDE with x2go on this server until I can figure out how to get it fixed.  All other x2go compatible window managers are working.

     If you do not have an existing Mate configuration and connect to this machine with x2go using mate, it will look like Windows.  If you do have an existing configuration then it will look the same as all the other Debian / Ubuntu derivatives.

     We do not yet have a corresponding yellow-snow.net web appearance but this is in the works.

     Received a report that people were unable to login to Debian this afternoon.  I found that ypbind had died but there was no indication in the logs as to why.  I restarted it and logins are functioning normally again.

     Slow service early this morning and the temporary unavailability of mail.eskimo.com was the result of a denial of service attack where upon our name servers were used as amplifiers in a denial of service attack aimed at us.  I had to lower the external view rate limit because of this, hopefully it is still adequate to service legitimate requests.

     There are aspects of this attack that I do not understand.  They forged an address of 204.122.16.248 from outside (udp packets so no three-way connect) and directed requests at 204.122.16.8, so our name servers would attempt to reply to 204.122.16.248 but there was no host on that IP address and the result was that our router didn’t know what to do with it and it overloaded it logging what it considered “Martian” packets.

     The puzzling aspect of this is I have a firewall rule that SHOULD block all traffic from an external interface which has an internal address.  I was able to mitigate the attack by blackholeing 204.122.16.248 at the name servers and rate limiting responses.

     Sorry I neglected to post the completion.  Reboots went smoothly, only Debian failed to properly remount file systems.

     I will be starting reboots now.