They certainly don't come from under cabbage leaves, but it's not obvious from reading the conferences where they do come from. Now I haven't been here a long time, but I have joined and lurked and read the coop, garage and helpers conferences. Granted, I haven't read every last article and comment, but it's not exactly jumping out at me either. While I see the occasional note about staff having more tasks than time, I don't see much in the way of how one becomes skilled or apprenticed into being a staffer. Would someone point me in the right direction, please? PS You can take issue with self-selecting volunteers, but I'm reasonably certain there are several ways to weed out frivolous wanabees.56 responses total.
I like this guy.
Well, what little procedure there is doesn't work very well.
What needs to be done to become a staffer is to win the trust of the powers
that be - mainly the existing staff and board. There are multiple kinds of
trust involved. We like a staffer who
- Has useful knowledge. You don't have to know everything about Unix, but
you need to know enough to get some useful work done, and you need to
know what you don't know.
- Is careful. Some people "oops" more than others.
- Is calm. If a user insults you and your mother and your dog, can you
manage to keep your response within appropriate guidelines? The ability
to resist getting sucked into pissing wars is vital.
- Understands Grex. Do you know what we're trying to accomplish here?
- Communicates. Staff need to talk to each other, and to users effectively.
So we need to know how a person reacts under stress, how reliable they are.
It's very hard to form such impressions over the web. And some people don't
start acting responsible until you give them responsibility. So the best
way to find out how people would work out would be just to give people root
access and see how they do ... except we are afraid of the flops.
So staff needs to develop some sense of the person. This is easiest for people
who live around Ann Arbor and whom we can get to know face-to-face. Otherwise
it's hard and we tend to be over conservative about it.
Probably a good starting point would be to let people know unambiguously that
you want it. Which isn't all that easy to do either.
The whole apprenticeship thing has been tried - with little success.
I wish I knew how to do this.
However, we _have_ successfully added staff from Australia, so it's not unheard of.
A few rambling thoughts: I think that part of the reason that staff activities have become somewhat opaque is that the staff doesn't get together for face- to-face meetings very often anymore. We used to have monthly meetings where we'd hash out various problems, and even discuss who might be likely new candidates for staff. For a while we even posted minutes of meetings (omitting security-related stuff). This stopped around the time that Valerie and Jan started having kids. Nowadays we're lucky to have as many as two f-to-f meetings a year. In the face of that, it's difficult to set new directions, and most of the staffers have carved out a niche where they do one or two particular tasks on an ongoing basis. That works for maintaining day-to-day operations, but new stuff -- like moving to the next generation of Grex hardware and software -- tends to languish forever. (I'm not implying that all staff members have to be local, but it does help to have a core group that can actually get together in person.) That said, I don't think the current staff is averse to new blood. But since we never get together to talk about it, nothing happens. Also, as somebody up there said, folks interested in doing Grex staff work should let us know. I can think of a few people who are active in this conference and elsewhere on Grex -- thus passing the "we know you and you know us" test -- who are well-qualified to be staff members, in my opinion. They haven't volunteered, though, and we haven't actively sought them out either. But if we know that you're interested... One problem that I don't see an easy way around: People with strong technical qualifications often also have a severe lack of extra free time to serve as unpaid volunteers.
This is a good point, John. I'm very busy in the middle of a PhD research program, and casual university tutoring. I would love to give more time to Grex, though it won't be huge amounts in the near term (I still plan to write backend software, similar to Backtalk, for a web-based party. As we move forward, I think it is widely recognised we need to offer a wider web-based GUI interface to applications on Grex, other than email).
I will be a little adventurous. I think Dan Cross would be a good staffer. He has the technical competency, the will to get things done, and the balls (skill, courage, and professionalism) to work well with Marcus and STeve on a range of complex/important issues (hardware, security, system software) - in my honest opinion. I'm sure he'd work well in our team as a whole, but he'd also add excellence that we have been extremely fortunate to have to date, but nothing is guaranteed into the future... Whilst we don't always agree with Marcus and STeve, none of us undervalues their contribution and opinions.
Regarding #6; Thanks, I'm flattered, but I honestly don't have the time now or in the forseeable future to give grex the kind of commitment it should expect from its staff members. :-( However, I don't mind helping out perioidically on well-defined things. If staff wants to tap me for a specific project, that'd be fine.
We don't demand any predefined time from any specific staff. If they can spare it, something gets done. I don't think you can expect much more on a volunteer system (especially during tough times in the industry).
The lack-of-time factor is definitely a general problem. But, as John said,
there's a fairly large degree to which staff people take on particular jobs
("have carved out a niche") that they can find time to work on. In some cases
(vandal cleanup, for example) this can definitely be on a when-you-have-time
basis; there's usually some of it needing doing, & several people do it as
they can make time. Unending, thankless job.
cross is one I also would have suggested. Just my $.02. I'm not on staff
and it's *just* my $.02.
Oh. One more thing. It's helpful to have folks on staff reading the staff
mail; but my experience (during the brief time when I was on staff) was that
this quickly got to be a large time-sink. Some folks are better at just
hitting that delete key than I am, & something may have been done to improve
things since then ...
s/large/huge/
Well, if that's the case, then I'd be interested. What's the procedure for getting involved?
(Dan's also been on my short list, and not just because he's still here two years later.) (I'll also admit to having been personally interested in joining the Grex staff from time to time. both the "cfadm" and "partyadm" functions seem like tasks that I could grasp, given enough patience. more recently, the disk-cleaning chores have interested me, mostly because it can be a time-sink and I have a surplus of time at the moment. however, it's always been that word "root" that scares me off.)
I'd support Carson working on disk cleaning; the fact that the word `root' scares him is, as I see it, a good sign that he's responsible enough. :-) But seriously, Carson's always struck me as a reliable and dedicated user. I think it's a good idea. On a related note, has grex thought about using something like sudo to give folks limited access for things like disk cleaning?
I'd like to re-look at the statement that "apprenticeships" haven't worked here. I'm not sure anybody's come on as an absolute beginner and served as long as many of the currently active Grex staffers. There have been a few of us (Mike O'Leary, Rob Henderson, Carl Miller, me, and probably a few other people I'm forgetting) who have started as beginners, put in a few productive years as Grex staffers, and turned our Grex staff experience into lucrative careers before fading away from the Grex staff. I don't know if Grex got as much out of my time on the staff as I did, but hopefully we both got something out of it. On that note, if somebody has time to work with him, I'd like to suggest jlamb. He appears to have free time, interest, and lots of potential.
I second jlamb but he has to promise to act older than he is. Jeremy has already set up his own little grex-like server with mail, party, bbs, and backtalk (FreeBSD).
I don't think this works by nominating and seconding in this forum. It's never that easy. ;-) At the last Board meeting we discussed the need to add more staff positions. STeve was going to take this to the staff, in mail, and hopefully bring some agreed upon and willing to serve candidate names to the next meeting. The Board usually votes to to accept the staff's recommendations. I'd suggest those interested and willing in helping out as staff either state so here or write to staff letting them know you'd like to be considered and where you think you could most easily help out.
I'm interested.
I'm interested.
Okay, I'll do it, but I'm afraid I can't promise much time.
I'm glad I was a little adventurous :) Hey, root is an exceptionally privileged role... BUT, there are many tasks you can do without root, or limit yourself to less risky root-tasks... The general rule is DON'T DO ANYTHING WITH ROOT ACCESS THAT YOU ARE NOT 1000 (yes 1000%) SURE IS SAFE, AND EVEN THEN YOU SHOULD TAKE CARE - Did I scare anyone off? It really isn't as hard as it sounds. But, care is needed! Knowing your limits, and knowing when to ask questions BEFORE taking a new activity on are both critical success factors.
Speaking in my current role as a consultant dealing with a lot of process issues for ISPs, I'd suggest some sort of change management system to ensure that nobody's diving into making system changes that aren't well planned in advance, but that's probably too bureaucratic for Grex.
Regarding #19; Bring it on! No, I'm just kidding; I try as hard as I can to do things as a user other than root (this includes creating a bunch of users to run specific services as), but that's just my style. Under Plan 9, which is what I work on most these days, there is no root user. Regarding #20; I once worked on an academic network of a couple hundred Sun's, Alpha's, SGI's, and the occasional other weird machine thrown in for good measure (VAXen running VMS, a DECstation or 2, some old Stardent Titans). The systems team consisted of about ten people. The arrangement we used worked pretty well; we had req for ticket tracking, all sysadmin activity was logged in req (this would be something like RT these days), all systems changes were done under RCS or SCCS (it'd just be straight RCS these days), all access to root was through a program I wrote called ``runas'' that checked a user's credentials before authorizing home or her to do something, and logged everything, (it'd probably be sudo these days), and once somebody changed something, they'd drop an email to an alias called ``changes'' that everyone got a copy of, and that got archived in a text file that we indexed with glimpse. If someone came up with a really clever fix to some sort of problem, they'd drop it to another alias, called ``sysinfo,'' to archive it for posterity. All in all, it was a really comfortable environment, and once everyone got used to playing by the ground rules (new hires, typically students who had limited experience and just knew ``you su to root to administer a Unix system'' were especially thrown off by runas and RCS), we almost never had any problems with people knowing in advance what was going on, or knowing who had changed what. I admit I'm frankly a little surprised that grex hasn't implemented a couple similar things; particularly something like sudo or runas to give limited access to root. If nothing else, the logging is really great if someone accidently messes something up.
(I've observed that Those Who Have Root have special root accounts. is that similar to either sudo or runas?)
re 21:
That's the less bureaucratic half of what I was talking about, and the
half of it which the Grex staff has done pretty well at times. The other part
is what happens before changes are made, in terms of whether the person making
the change figures out how to do it on the fly, or has everything carefully
planned out, step by step and command line by command line, along with testing
and backout procedures, beforehand. It's that last bit that really prevents
outages, but as I said it's probably too bureaucratic for Grex.
Carson: No- woot, soot, moot, etc all have equal root privileges (i.e. same root UID). They're possibly there to each have their own home directory, and for logging/audit reasons? Any of us with root-level access can simply login as root, though this is not desired (correct me if I am wrong other staff?) Perhaps staff who preceeded me could ellaborate/clarify the reasons for the alias root logins.
I think it's mainly for accountability -- knowing which root did what. And to give each person with root privileges their own "root" directory. There are a number of administrative tasks that entail modifying certain files and directories but don't require full root access. So far that's been handled via special accounts and groups -- for example, there's the "cfadm" account for the conference administrator and the "partyadm" account for the party administrator. "Sudo" might be a better tool for managing that. I don't think we have it on the current Grex, but we certainly will when we move to OpenBSD. I'm really glad to see folks expressing interest in doing staff work. Some of the folks speaking up are ones that have been in the back of my mind as potential staff material.
Maybe this is a good time to review the procedure for adding new staff. Basically, current staff discusses candidates and makes a recommendation. If the position requires access to root, the staff conference, or the staff mailing list, then the recommenda- tion must be approved by the board. So far, the board has just rubber-stamped whatever the staff has recommended. But the requirement of board approval insures that there's public discussion and a record of the appointment in the minutes, which I think is a Good Thing. So for example, if we wanted Dan Cross to do a project that required limited privileges but not root or access to the staff conference or mailing list, then current staff could just give him the resources, with no board approval required. If we wanted him to be a permanent staff member with access to any of those three specifc things, the board would have to vote on it.
Regarding #22; So far as I can see, all of the *oot accounts are functionally equivalent to root. Sudo gives you more fine-grained control over access to priviledged functions, and does logging. I don't see anything about the *oot accounts that tells you who did what. Regarding #23; Yeah, I think you're right. We did a lot of that stuff in req and face to face meetings on a blackboard. It wasn't as formal as in industry, but served the purpose well enough. It's probably impractical for grex. Regarding #24 and #25; The thing about home directories I guess I can kind of see; sudo would do away with the need for that. But logging or auditing; it doesn't seem like it would help out much. I guess if each root account had a history file, it might; but sudo would fix that by logging to a central place. Otherwise, there's not much of an audit trail to follow. That is, I don't see how one can tell which root did what. In general, I like the idea of moving seperate administrative tasks to other accounts and/or groups. I think it's a good way to partition the access space. Regarding #26; So, what happens now? I think four or five people have either volunteered or been volunteered for staff. What kind of turn around time are we looking at?
There is no turn around time guarantee - but, I assume staff can discuss this and bring a list of candidates to the next BoD meeting, for approval.
Dan's suggestion is good. Using 'sudo' for root tasks should be considered for the next Grex, at very least. It solves a lot of tricky problems. You can even restrict people to being able to run some programs as root but not others.
Actually there's one task anyone could do, which would help with doing stuff
via sudo - writing scripts to do a lot of the dumb stuff we do on a
case-by-case basis. Granted I should do a few myself, but I'm terrible at
starting projects. Stuff like deleting any bots/bouncers from a home
directory, maybe checking in /tmp for same, and leaving a warning-message
file.
One problem I can see with limiting things to scripts is that a lot of vandals
and IRC bot/bouncer people tend to try to bring things in with different file
names, put them in "hidden" ("...") directories, and other things. So
ultimately we're still faced with having to give somebody permission to delet
random files in people's home directories.
I wanted to restart this item; has any traction happened on this? It seems like it's important enough not to let slip through the cracks.
I WANT TO BE AN IRC OPERATOR!
The usual procedure is for staff to discuss staff candidates at a (closed to the public) staff meeting. We should really have one of those, sometime soon, to discuss the next steps on the next grex, and other issues. Board approval is then needed to formally add people to staff. So there is going to be a bit of a bureaucratic time delay. In the meantime, candidates may like to make themselves useful. Participate in the discussions in garage. I'll give people likely to have a contribution non-root accounts on the new Grex machine (Dan, for instance, has run some benchmarks there). People interested in being staff might help us in giving us a clue as to what kind of role they see for themselves.
Just curious here - would you think you'd get more staff involved in selecting new staff if you had this discussion face-to-face or in email?
Some staff don't read the conferences, some staff don't read email, some staff don't attend meetings. Any medium works, if only you can get people there.
This response has been erased.
One thing that occurs to me is that it might be useful to have a clear list of who wants to be on staff before the next staff meeting (whenever that is). It would certainly make the discussion a bit easier if we were clear on who we were talking about and what capacity they were interested in serving on staff. If people post here, or send email to someone (not staff@grex.org - that's really only read once a week by srw) if you prefer not to make a big public noise. I think the following people have made noises about being interested in being on staff. kip - root staff cross - root staff other - non-root staff carson - dunno gelinas - dunno I've had time to talk to kip about this. I've talked to many of the others about many other things, but not about this. If Dan is actually interested in working on staff, I'd be interested in hearing how he sees this working. Neither strong opinions on how things should be done, nor living too far away to be able to attend meetings are disqualifications for being on staff. We have staff members in each catagory. But we've never had one in both categories. Face-to-face meetings are usually the best way to resolve divergent opinions. We did manage to converge pretty well on the discussion of RAID in the garage conference, so perhaps the problem isn't hopeless, but it does worry me.
(I'd be interested in being a partyadm [and cfadm, although less so]. that said, Grex could certainly use more than one new partyadm at the moment.)
I want to serve in any capacity needed, up to and including root staff.
Oh, don't worry about that. My opinions are just that, opinions. I do have a tendency to argue for them strongly---too strongly at times---but I wouldn't force anyone to do anything they didn't really feel comfortable with, and when I'm in a position of responsibility, I tend to mellow out much more. That is to say, it's easy to be an advocate from the outside, it's much harder to do so from the inside because all of a sudden you're much more aware of all the constraints you're facing, and it's better to just be pragmatic, which often means compromise. Back in the day when I was a sysadmin, many of my collegues would laugh at overzealous graduate students who wanted to replace existing large scale systems with things taken out of research. I prided myself on taking a middle ground, where I would recognize that yes, perhaps that was the *right* way to do it, but unworkable given the real world complexities of the system in question. I often advocated for thinking along the researcher's lines and looking for a way to incorporate their work, even if it wasn't practical to do a complete reimplementation. Also, bear in mind, I'm a New Yorker and was born in raised in the Northeast. Being confrontational is in my nature. However, if you met me in person, I think you'd come to find I was actually a pretty easy going and friendly guy that doesn't like conflict except in the good-natured sort of way you find amongst people hanging out on a stoop in Brookyln.
I hereby wish to appoint gelinas, carson, and other as partyadm's. Can I have another staffer second my recommendation, please?
Seconded.
This is a two-parter. 1. I'd like to see cross giv en a position, if he still wants one. He seems to be a responsible, respectable guy, and to have self-confidence, rahter than arrogance. 2. I'd like to volunteer to be a staffer. I'm new here, but not new to UNIX/Linux. I have been running Linux for a total of about 4 years now, tho my present system is currently a WinXP (a situation i hope to change in the near future). Aside from anything else, i'd like the following points to be considered: When it is available, UNIX/Linux is my primary system. This means i don't just tinker with it from time to time. I've been known to sit and unalias MDK's rm and cp, etc. from "rm -i", to avoid making mistakes on other systems and get too comfortable with rm etc. I'd like to state upfront that I am in the UK (as many of you will know already), with zero chance of being able to come to the US for the foreseeable future. On the plus side, I presently have a lot of time i can devote to GREX, tho i hope this will decrease in future by virtue of getting a job. However, I don't plan to disappear once in gainful employment. If there are any jobs that need doing that can be done without root privileges, i'd be happy to do that. GREX needs people. I'd be honoured to be one of the people GREX needs. 2a. I'm glad UNIX command spellings don't change depending on what side of the Atlantic you're on :P
Addendum Did i mention i'm somewhat familiar with FreeBSD (and therefore *BSD)? And if you're loking for someone with fw experience, maybe i could try in a few years ago, but right now a UK conf would be a great idea.
Thanks for the vote of confidence, I appreciate it. However, I would be remiss if I didn't admit that I *can* be arrogant at times. :-)
No problem, and duly noted :P. And of course, that "years ago" in #44 should be "years' time". My 2 pence :P
Re #45: Wow, that would be unusual on the Grex staff.
Heh. :-)
I would volunteer to be on staff, cept that I know very little about unix :P
I don't think you necessarily have to know a lot about Unix to be on grex staff. The requirements are more, I believe, related to knowing about grex and being generally trustworthy. You probably qualify on the latter, Sapna, and I *know* you qualify on the former. :-)
You are way too trusting, Dan ;) If I didn't know much about Unix, what would I do if I were on staff?
Pretend you know something :)
There are plenty of things one can do on staff that don't have much to do with knowing a lot about Unix. Answering user email and looking for disk hogs come to mind. I suppose there are other tasks, but I'm just getting into it, so I'm not completely sure what they are. Perhaps someone more experienced can comment?
This response has been erased.
TROGG IS DAVID BLAINE
NOTHING LIKE THAT SCWIBBLE SCWIPT
You have several choices: