Access to the Webspace Service was restricted to the lab's Network on Monday, July 29.
LBNL users can continue to access webspace from onsite, or via VPN. However, many non-LBNL users use webspace to share files with LBNL collaborators. During this restriction, these individuals will not be able to use webspace. This impacts users of the website as well as the desktop client on all platforms. It impacts both logged in users and users of "tickets".
IT recommends the use of Google Drive as an alternative to webspace. By creating folders in Google Drive, you can upload files of any type and share a link to external non-LBNL users. You can choose whether to require login, or allow “anyone with the link” to access the folder. All lbnl users have 30GB of shared storage between gmail and google drive, so most users should have plenty of space to share files. Information on how to share files in Drive is available here: https://commons.lbl.gov/x/X4KmBQ
Google has a more general help article as well: https://support.google.com/drive/answer/2494822?hl=en
We apologize for this inconvenience and will update when you when Webspace is once again available externally. In the meantime, if you need any assistance using Google Drive or finding another tool for sharing files with collaborators, please contact us at [email protected]
For additional information on this restriction, visit the Webspace Service Announcement page.
UPDATE: 8/13/13
Our vendor has provided a patch that we plan to implement on Thursday, August 15 at 5pm. The outage window will last approximately 3 hours. Once completed and we complete a security scan, Webspace will once again be extended beyond our network. (This means tickets can once again be issued and used by non-LBL collaborators).
Google deployed a full-screen mode for the New Compose in Gmail and it is now available to users at LBL.
From Google's announcement ....
Key combinations:
Hold down Shift when you click the full-screen icon to pop the window out entirely. Holding Shift when you click Compose (or keyboard shortcut c) will also start a tear-off.
The formatting bar also shows by default now when you open compose in a new window or in a new tab (Ctrl+Compose or keyboard shortcut d).
Try it out
You can use it on an as-needed basis, or if you prefer, you can make it your default experience. To try it out:
1. Click Compose.
2. Click the double-arrow icon at the top right of the compose window.
3. Enjoy a larger composition mode that displays all of the formatting options by default.
If you want to make this option your default view, click into the options menu at the bottom right corner of compose and choose “Default to full-screen.” The next time you click Compose, you’ll be sent to this mode. Both types of compose can be minimized by clicking the black bar at the top.
Some of our institutional systems will be unavailable Saturday due to electrical work in the IT Data Center.
The planned outage window is from 12 noon to 5PM, although some applications will be impacted for a much shorter period of time.
At this point, the applications that will be impacted for all or part of the outage include:
Facilities Maximo application
- AMS (Sunflower Asset Management System)
- BRS/Cognos
- All centralized Windows file (CIFS)services (shorter down time and recover automatically)
- Commons ( ~ 1 hr) - includes a number of web sites and wiki's (including facilities, HR, IT, the Lab RPM)
- eBuy
- IRIS
- LETS
- Maximo
- Peoplesoft HRIS
- Peoplesoft FMS
- Peoplesoft TREX
- Sophos Antivirus Server ( ~ 1 hr)
- Webspace
- Windows printing - LBLPrint1, 2, 3, and Engineering ( ~ 1 hr )
Background
On Thursday, July 11 at 2:30pm, the Lab conducted a real evacuation of the hill for selected buildings. In parallel with this event, all lab employees were encouraged to check-in to report on their personal status as part of the drill. Some groups used traditional phone trees, text messages or email to report out, while others used a Google based application to record similar information (and some used a combination of both methods). IT offered to develop the Google Application during the planning process for the exercise in the hopes of reducing the burden on Divisions.
The Check-in Program
The application was designed to be a pilot, not the eventual application that the lab might make use of in a real emergency - it was designed to help us learn about how people would use the application in an emergency. Because of the very short time between our offer to develop the application and the drill, we implemented the program in Google Apps Script, a scripting language that is provided as part of the Google Apps Suite which generally provides a reasonably quick platform for simple development projects.
The application we implemented allowed people to to check themselves in, and also provided supervisors with the ability to report on members of their group. In addition, an effort was made to provide feedback on progress by Organization, Building or supervisor level. The application was tested and worked well - until the actual evacuation drill. Limitations on resource usage (implemented on Google's end and undocumented) caused the application to stop processing new entries very early in the exercise.
As a result, out backup plan was brought into operation 8 minutes into the drill (at 2:38pm). A simple Google form with a Google docs spreadsheet as the data collection engine was developed. Over 2400 entries were subsequently recorded and reported on using this method. While it was effective in collecting results, we did not have the ability to report out by supervisor, building, and division during the early part of the exercise. We implemented this as the exercise continued, eventually delivering reports by Division by around 6pm and further refining them by 9pm and then again the next morning. By this time, most of the interest in the data was at the division-wide level and few supervisors saw the reporting roster.
Lessons Learned
This experience gave us two sorts of lessons, one set about Apps Script and the other about what functionality might be in a future application.
In terms of Apps Script, we need to determine whether applications can be implemented to scale appropriately to hundreds of concurrent users. We have already had discussions with the Project Manager of Apps Script about this. More broadly, any future production application for this purpose would go through the normal IT development process with direction from the functional owner (protective services). We will of course continue to favor applications/platforms that are hosted externally on robust infrastructure to support disaster recovery.
In terms of lessons learned about functionality, two things stood out to us. Many users complained about the difficulty of logging in to the application. Finding the right balance between ensuring that users of the application are really who they say they are, and making it convenient to check in is an important balancing act, one which a future application needs to address. This call would be made by PS, but from an IT perspective, our sense is that allowing unauthenticated checking, but requiring a login to view other data is a good balance. This leads to the other observation: there were many requests for access to the data that didn't follow the model of supervisors and hierarchy. While this was almost certainly related to the failure of the original application, in a real emergency, there would no doubt be many people with different needs to access the data - as a general rule, hierarchies aren't that useful in emergencies. In addition, quirks of LBNL like matrixed employees further complicate reporting. A flatter data model (all logged in users can view all data for the lab) might be the right way to go.
IT would like to apologize for the confusion resulting from the issues with the application. We made substantial efforts to QA and test the application in advance, but we did not expect the application to trigger Google App Script use limits the way that it did. We look forward to the opportunity to support a labwide checkin application in the future if this work is supported by PS and the lab community.
