June 2012 - Core-students - mailman3.cels.anl.gov

one more thing about svn
by Ken Raffenetti 28 Jun '12

28 Jun '12

One more thing that I forgot to bring up at the meeting, the 'svntrac' resource in userbase. Currently this resource does nothing, which can be misleading to users because the helpdesk often tells people to request it to get SVN access. SVN and Trac access only requires an active MCS account or an svn guest account. 'svntrac' was created in the past because an active MCS account didn't guarantee a user an entry in NIS/LDAP. That is no longer the case. I would propose we remove the 'svntrac' resource entirely to avoid any confusion. I'd like to hear if anyone thinks we need to keep it around. -- Ken Raffenetti Systems Administration Associate MCS Division - Argonne National Laboratory

2 1

Where's Corby
by Schmitz, Corby B. 28 Jun '12

28 Jun '12

In training from 1-4:30 today in 201. If you need me, call my cell as I don't think we are allowed to have laptops open during the class. Tomorrow morning I will be working from home until Sheri comes back from an appointment. I expect to be in the office by 9, but it may be earlier. -- corby

1 0

Today's user termination list
by stace＠mcs.anl.gov 28 Jun '12

28 Jun '12

Full list of people who no longer appear on the active employee list =========================================================================== 65820 PSC Hackley, Vincent A. 67650 PSC Sauer, Linda K. 83656 PSC Hilbert, Brendan J. 83984 MSD Zeng, Xiaoqiao 212197 PSC Pascarelli, Maria (Sakura) 216645 PSC Burcusa, Michael R. 219752 PSC Bautista Oviedo, Emil G. 219962 HEP YE, Shuwei 219974 PSC Lee, Han Youl 220056 PSC Merte, Lindsay R. 220062 PSC Matos, Jeronimo 220065 PSC Goundie, Benjamin M. 220066 PSC Lapatovich, Walter P.

1 0

Re: Membership in core-staff
by Craig Stacey 27 Jun '12

27 Jun '12

(Moving this to the core-admins list, since this has broader implications) I made the text in the description for the e-mail address field more descriptive. Via the interface, it used to say "Provide an external email address you can be reached at in the event your CI email address is unreachable.", which in no way encourages people to add multiple addresses. If we're going to treat the address they enter first as their primary address, we need to encourage that to be the CI address, and have them provide others after the fact. The box now says: Enter one e-mail address in the above field. You can add addresses one at a time via this form. The first address you provide is your primary address. If you have not already done so, provide an external email address you can be reached at in the event your CI email address is unreachable. The problem with this is that during the account request process, they can only provide a single address and there's no mechanism to provide more than one. We want them to provide an external one, but we also want them to provide their "primary" address. I'm thinking of ways to solve this, but we should brainstorm on this at the meeting tomorrow morning. -- Craig On Jun 27, 2012, at 6:23 PM, Craig Stacey wrote: > I just made a Userbase resource for core-staff and added everyone to it. A side-effect is that it is using your primary e-mail address in Userbase to subscribe you, so some of your are subscribed twice. Zimbra will mash the dupes, I'm pretty sure, but you may want to look at your own userbase record and make sure your primary address is what you want it to be. > -- > Craig >

1 0

Changes to userbase unix groups
by Chris Walker 27 Jun '12

27 Jun '12

Yesterday, I deployed a new version of Userbase. This version makes a significant improvement to how resources of the unix groups variety are handled. Now, *any* resource in userbase may have an associated unix group simply by providing a gidNumber value and a group_name value. You'll see those fields listed in the add/edit resource dialog. There is also a "next gid" link on the dialog to set the gidNumber to the next available value, so no more digging to find an available GID. The group name is the actual text used to name the group, no filtering, conversions, etc are done. So make sure the name you give it is a valid, legal group name for your environment. I've copied the value from the name field to the group_name field for all resources with a gid, since userbase used to use the name field for the group's name. So as of now, any given resource in userbase can have: - a mailing list - an ldap netgroup - a unix group The key factor here is that we're not pointing the resource at a group resource. This means there's several redundant resources floating around userbase, and it would do us good to eliminate these. I believe we've done this already with IGSB, but other resources have corresponding group resources that need to be merged if the operational use of the group is identical to the resource.. Please take a moment and review the resources you care about, take care of, etc. and try to determine if there's some cleanup we can do. Then we'll work together to get it sorted out.. Another highly useful new feature are script execution conditions. While not entirely new, it is the first time we've used it in production. MCS is now taking advantage of this, the remaining domains will follow along once I'm satisfied everything is behaving as expected, so probably Monday. This feature lets us define what conditions need to be met in order for a script to get queued for execution. For example, before this feature, every time someone was added to a resource, userbase called the script to add the user to the resource's mailing list, even if the resource didn't have a mailing list defined. Now, userbase can check the values of a field (or related object's field) and decide if the script should run or not. What this means for everyone is that once deployed, any script failure is a "real" failure that indicates some sort of truly bad thing has taken place. You'll notice on the Manage page, I've added a tab called "Recent Script Failures". Over time, we'll see that number decrease, and hopefully reach 0, and stay there. On the front-end, the account sponsorship page has been expanded out quite a bit. There are now pages for: Approved Accounts Denied Accounts Suspended Accounts Approved Resources Denied Resources Suspended Resources It's my hope this makes it easier for sponsors to understand what they're looking at and what they're supposed to do. The significant change here is that the lists are not date sensitive, so all sponsorships matching the list's criteria are listed (with paging, of course). Thanks for playing along, happy userbasing! - Chris

2 2

Craig Stacey wants to share "CELS Admins" with you
by Dropbox 27 Jun '12

27 Jun '12

Craig (stace(a)stace.com) wants to share some files with you using Dropbox. Message from Craig: "This is the temp repo for shared docs until our sharepoint is ready. Nothing sensitive here, please." View the "CELS Admins" folder here: https://www.dropbox.com/el/?r=/link/17.y_1djSScOB%3Fk%3D106ce86303c323a97af… Enjoy! - The Dropbox Team

2 1

Agenda and Notes for Weekly Services Meeting, 6/28/12, 9:30 AM - 10:30 AM
by Craig Stacey 27 Jun '12

27 Jun '12

1 0

Today's user termination list
by stace＠mcs.anl.gov 27 Jun '12

27 Jun '12

Full list of people who no longer appear on the active employee list =========================================================================== 41710 DIS Nieves, Alvaro L. 64329 PSC Nishiyama, Norimasa 83111 PSC Scott, Robert W. J. 211395 PHY Ziebinski, Marek 217647 CNM Balasubramanian, Shankar 218840 ES Wang, Hewu

1 0

MREN Email help
by Schmitz, Corby B. 26 Jun '12

26 Jun '12

I am working on a project to do fancy things with the MREN email systems. Here is what I want to do: trouble(a)mren.org – currently doesn't exist, but I want to point this at a new RT ticket queue (mren-noc). I can create the email alias pointing at any address you like. I would like the reply-to on these to be trouble(a)mren.org if possible for cleanliness Announce(a)mren.org – currently a statically managed list on the CIS side. I would like to remove this and turn it into a mailman list with web archiving. It should be available for self enrollment, but restricted posting (probably just a select few at ANL) Emerg-announce(a)mren.org – currently doesn't exist, but I would like to have another self-enroll list with limited posting abilities (like the announce list). This will be used for registering secondary addresses to be used in the event of a serious MREN failure Does this sound like something that can be hosted out of MCS? -- corby

5 20

repocafe prototype
by Ken Raffenetti 26 Jun '12

26 Jun '12

A repocafe installation is now functional at https://humphrey.mcs.anl.gov/. Please login and poke around if you have a chance. Create repos/groups/guest accounts if you'd like. We can discuss next steps at the services meeting Thursday, but I'd like to have eyes on it before then. -- Ken Raffenetti Systems Administration Associate MCS Division - Argonne National Laboratory

1 0