Some issues remain on the upgrade from collab.mcs.anl.gov (Confluence v4) to collab.cels.anl.gov (Confluence v5). Primarily, the firewall exceptions to allow access from offsite are not yet in place. I’ve put in a request to have that done as soon as possible, and with luck should be in place before too long.
Secondly, any custom images you’ve uploaded into your space may not have transferred properly. We still have the old database and server, so please take a look at your spaces in Confluence and let us know if there’s data, images, or info you need recovered.
We’ll send another announcement once the firewall issue is fixed, but in the interim is should be accessible from any internal network, including the VPN.
As part of our plan to merge the contents of Confluence running on xcollab.mcs.anl.gov and collab.mcs.anl.gov we will be moving https://collab.mcs.anl.gov/ to https://collab.cels.anl.gov/ and upgrading the Confluence software from 4.3 to 5.7.1
This hostname migration will occur late Saturday May 2nd (2015-05-02). During that time, it will not be possible to update or add pages to your Spaces on https://collab.mcs.anl.gov/.
Once the migration is complete, the site will be replaced with a link to https://collab.cels.anl.gov/ and will eventually be brought off-line entirely.
Once https://collab.cels.anl.gov/ is up and the migration is completed, users browsing the old address will be shown a notice directing them to the new address.
During the following week we will work individually with owners of Spaces hosted on https://xcollab.mcs.anl.gov/ to migrate them to the new server as well.
This message applies to the people who are connecting to Dayforce via rdp.mcs.anl.gov rather than some other method. If what you’re doing is working for you, you can safely disregard this message.
Recently, a Google Chrome update disabled native support of NPAPI plugins. This affects a number of plugins, including Silverlight, which is required by Dayforce. There is a workaround, which I’ll go into shortly, but the issue remains this is a temporary workaround and we can expect Chrome to remove support (rather than disable it) eventually.
So the real fix is to switch to Firefox. As such, I’ve added a new shortcut to everyone’s desktop on RDP labelled "Dayforce (via Firefox)". If you launch that shortcut, it will eventually get you to Dayforce (it may ask you some first-time Firefox user questions such as importing bookmarks and choosing a default browser). You’ll eventually need to allow the Silverlight plugin, which it will remind you to do. Make sure you "Allow and Remember" to prevent it from asking every time.
If you wish to continue using Chrome, you’ll need to take an extra step after launching the old Chrome shortcut. You’ll see a page like this:
Ignore step 1. Silverlight is installed, it just doesn’t know it. You need to follow the rest of the steps, however, to get Dayforce to start working again. Once following those steps (including relaunching) Dayforce will work in Chrome as it used to.
Again, this only applies to people using rdp.mcs.anl.gov to get to Dayforce. If you’re happily using http://dash.anl.gov (the officially supported method), or using your own browser and silverlight extenstion, you don’t need to change what you’re doing.
Below are the specs on our recommended equipment for this summer. Feel free to request a desktop,
monitor or both as needed. We can also help spec out a laptop if that is what your visitor prefers. To ensure your equipment is here prior to your visitor’s arrival, please
submit your orders or any questions to email@example.com before Friday, April 17th.
If nothing is submitted to us by April 17th, we will assume you have made other arrangements and
we won’t be able to guarantee we will have anything available on their start date if this changes.
Lastly, if possible, let us know who your order will be associated with so we can get them distributed easier when the machines arrive.
As always, let us know if you have any questions!
We’ve revised and updated the laptop support policy for CELS in order to address some holes in our process from a cybersecurity standpoint, and to offer those who may not want a fully managed machine some avenue to receive support and notification for patching and other security issues.
You can find the updated policy here: http://www.mcs.anl.gov/faq/Laptops
You can see the history tab on the wiki for changes, but the main change is defining the categories of laptops and what each entails. We’ve added a category of machines targeted at scientific users who would like to share the administrative burden of their machines with us. In that case, we’ll notify you of important software updates and can apply them for you as desired. We will also handle software license compliance and reporting for those machines.
As new laptops are ordered, we’re going to be offering any researcher the choice of jointly managed or unmanaged configurations.
If you have any questions or concerns, please let me know. Thanks!
This work has been completed without incident.
On Saturday, February 21 at around 12 Noon we will be rebooting the Macintosh file server named “bronze” in order to apply some important software updates.
We anticipate a very short downtime window, but in order to give us some room to take care of any unanticipated issues that might arise I am setting the downtime window to be from 12 Noon until 1 PM. If you see any of the fileshares reappear during this time you should not expect them to remain stable.
On Friday we will send reminders to anyone logged in to the server. It’s a good idea to make sure that any open work is saved and that you are logged out of the server at close of business on Friday.
When the work is done an all-clear will be sent and posted at the Systems blog: https://mcssys.wordpress.com
If this poses an unacceptable disruption for you please send a note to firstname.lastname@example.org
The ANL Cyber office reports increased phishing activity, some of it pretty well executed. They’re taking advantage of the fact that it’s tax season to try to get you to open documents. Please be mindful of this when opening any documents.
Some good practices for you to engage in:
1) Do your best to keep your personal activity in your personal mailbox, rather than your ANL mailbox. This way, you’ll notice a red flag if see e-mail claiming to be from your bank e-mails but coming to your work address. Free personal e-mail accounts can be trivially obtained from Google, Yahoo, and Microsoft. Also, your internet provider usually provides an e-mail account you can use.
2) Look at the mail headers of any message you receive that purports to be from a trusted source. It might claim to be from somewhere you trust, but it really isn’t. And, trust me, I recognize the irony that Argonne broadcasts like Argonne Today don’t come from anl.gov servers. That being said, they also don’t come from some Italian ISP, so if you see that in the headers, it’s a sign.
3) And, the mantra we’ve always touted forever and ever, don’t open any attachments that you weren’t expecting or don’t know what they are. If in doubt, ask the sender via a trusted method. Or ask us. We’re here to help.
If you like goofy mnemonics or catch phrases, Cyber is touting "SEAR the phish". Where SEAR means Stop, Examine, Ask, Report.
Stop: Don’t panic and don’t be too quick to click on email links even if the message looks urgent and threatening. This is NOT a contest where being 1st to click wins.
Examine: Look at the email closely. Does the message look suspicious, does the link look unusual, does the request make sense?
Ask: Question the sender (if you know him/her personally). Check with the Cyber Office (email@example.com) to determine if the email is legitimate or not.
Report: Notify Cyber if you receive any phishing emails by forwarding it to firstname.lastname@example.org
Stay vigilant, folks! Thanks!
It looks like the networking issues from yesterday have been resolved.
All told, there were three outages in total. The first was at Sunday 4AM, the second yesterday early afternoon, and another one that followed shortly after. The current theory is the failures were caused by an intermittent failure in a network interface card on one of the lab’s firewall servers. The firewall functions were forced to move to the redundant server across campus, which seems to have stabilized the situation, and will allow the failing one to be repaired.
Thanks for your patience!