55 new of 85 responses total.
resp:29 Agreed. resp:30 The new newuser needs some cleanup, but overall, I think it's a lot less crufty than the old newuser.
re 18 ... uhhhhh.... We need the email address to email the password to the user. Newuser generates a password and emails it to the user. let;s not do that .... struturally it;st not a good idea. keep resh and with the modificatoins./clarifications that validationg is goign to require email -exchange- with someone staff/board on grex. i.e.. after crateing an acount (and the laert in newuser that other-email-addrs is needded for validation) a validationg rqeust can be sent. sent by the newuwer from (possibly other-email-addrs) or frm grex-email, whichever. emaikling passwds makes me puke.
What's not a good idea about mailing the password? This isn't the Pentagon or anything. We've talked about an an offsite e-mail address being more or less required, as in automatically send the user an e-mail and they can respond and be validated. It also gives us contact information if there are other issues (including forgotten password). I suppose we could require the password be changed when they first log in. Or at least, suggest strongly that they do so in the e-mail we send.
resp:32 Why? resp:33 Resh requires the new user to change their password the first time they login. Actually, it requires them to change whenever there's a certain file in their home directory.
Okay, then, sounds like we're in good shape.
first of all .... about emailing passwdds... whe a newuser cone here she/he/it creates a passwd. wtf is wrong with that? notiohing. second, the balidation is a time dalya, eveninfit is 30 secs. third. hte eamil to the newuser may ot be read (or it might og iotn some spam foledre) and be unknown for monthsl. (rt stuff is expeirience as is ... my emaoil).. i ahve validated .. well tried to valisdate ... reaped loginds .. which prompted me ... a wheil aago ... to ask aobut hte reapo preocedure. wheat i had to send was "well create your loginid AGAIN .. and i wiell validate" fourth .. a passwd distting around for a whiel is STUPID (imnsho) wheich is also different from the newuser's orogianl choice .. w t f ? there is more but the above is enough, i think.
I'm going to address your post point by point. I'm also going to take
the time to fix your spelling errors.
> first of all .... about emailing passwords... when a newuser comes here
> she/he/it creates a passwd.
That's not true anymore; the user isn't even prompted for a password.
Further, there's nothing that says that they *have* to give a password
to newuser.
> wtf is wrong with that? nothing.
Actually, it became a vector for abuse. I have caught specific people
making *thousands* of accounts with scripts. This way, at least we can
track that back to an email address.
Second, by generating the passord and emailing it to the user, at least we
have some sort of useful contact information: if the user logged in at all,
we know we've got an email address for them.
Lots of sites do this: ask for an email address and email an auto-generated
password to the user. It works just fine all over the Internet.
> second, the validation is a time delay, even if it is 30 secs.
What validation are you referring to? The automated validation of the
email address that newuser does? I'd say that in the worst case that
might take half a second.
Or are you talking about how long it takes for the user to get the email
so they can login for the first time? It takes a few seconds. The upsides
are worth it.
> third. the eamil to the newuser may not be read (or it might go into
> some spam folder) and be unknown for months. (rt stuff is experience as
> is ... my email).
It strikes me that if a user is interested in getting an account on Grex,
they won't mind getting an email with their password. Evidence of this is
all over the net; it's more common than not for users to get passwords
emailed to them than otherwise. If they wait for months, well, that's on
them and they weren't likely to be very interested anyway.
What's the difference between a user logging in once automatically at the
end of creating their account and never logging again, and never logging in
because they didn't bother to read the email that we told them they were
going to get?
> i have validated .. well tried to validate ... reaped logins .. which
> prompted me ... a while ago ... to ask about the reap procedure. what
> i had to send was "well create your login id AGAIN .. and i will validate"
I don't know what this has to do with newuser emailing passwords, except
perhaps an extension of the above paragraph about the user not reading his
or her email for months. Newuser is pretty explicit about telling the
user, multiple times, that it's going to send them email. If they choose
to ignore that email, then they're just as likely to login to resh, see
they can't run BNC or upload udp.pl and disappear after one login.
The policies and criteria by which we decide to reap accounts have not
changed for years. If it takes the porters months to do validation, then
that's a real problem.
> fourth .. a password sitting around for a while is STUPID (imnsho)
> which is also different from the new user's original choice .. w t f ?
What do you mean, "is also different from the new user's original choice"?
Do you mean a password that they enter, or a password that they have in
mind when they create an account on Grex? If the former, they don't enter
a password. If the latter, I claim this is actually *easier* on them
since they don't have to sit there and think of one.
To be clear, here's the basic process for getting an account on Grex:
1. Login as newuser and enter your basic information:
a. "Real" name.
b. Email address.
c. desired login name.
d. Currently, a few other questions: address, phone number, interests, etc.
* Note that password is not on this list. *
2. Newuser generates and emails you your password.
3. User gets the password, logs in and is in resh. Resh sees they've
got a special file in their home directory (I believe I named it,
".needspwchange", but I can't remember) and prompts them to change
their password.
That's it. Suppose we go on through the validation process.
4. User goes through the validation process:
a. send email to porters@grex.org with the request,
b. get an email back saying, "How'd you hear about Grex?"
c. user gives some response (really, any response will do),
d. a porter runs "validate user" on Grex, thus changing their
primary group to "people" and changing their shell to
/usr/local/bin/newly-validated (this will move to /cyberspace/bin
soon, though; the path is unimportant).
5. User logs in again (note that they changed their password the first
time they logged into resh; it doesn't change at all during the validation
process). Newly-validated chgrp's their files to the "people" group
and invokes /usr/local/bin/pickashell (again, this needs to move to
/cyberspace/bin, but the path doesn't matter); the user picks what shell
they want to use and away they go.
Now the user has real access to Grex. Supposing that they wanted the
full, unrestricted access, then go through the existing procedures, which
haven't really changed since Grex was created, to get verified: basically,
this means that they send a copy of an ID or a personal check or use
paypal, at which point someone runs "verify user" on them, which changes
their primary group to "verified" (and that's basically it; it also adds
them to "people" as a secondary group).
What I'd like to do, and what board talked about somewhere on the order
of three or four years ago, is add an automated verification system.
Basically, the user types "verify" or something on Grex, gets a URL that
they click on, they pay a couple of bucks or something through PayPal,
PayPal contacts us, we verify the payment and automagically verify them.
> there is more but the above is enough, i think.
No, I'm afraid it is not.
You are making a lot of flimsy assumptions (that the user won't
read their email, or that it will get marked as spam) and predicating
your argument on things that haven't been true for years (that the
user comes to Grex with some idea of what they want their password
to be, probably also that this is some sort of huge security risk).
It isn't 1991 anymore.
I think that what newuser is doing now is actually much better than
the old system:
a. It avoids abuse.
b. It gives us much higher quality contact information (we actually
have an email address that we know works in case the user forgets
his or her password).
c. It makes contacting the user simpler: we can look at newuser's
contact logs to get a user's email address if we want to send them
a message, instead of digging through their personal files (which
TS does regularly in order to find email addresses for validation
purposes).
d. It gives an air of professionalism to Grex that, I claim, will
increase users, not drive them away.
e. It follows well-established and widely used precedent. Indeed,
even on Grex, when we reset someone's password, we just send
them an email.
Does anyone else feel that emailing the password to the new user is
bad?
well.. i'm not clear on one point.. 1. we ask for his email and mail him his password, AND put him in resh? How does he move from resh to bash?? 2. we can try to avoid the spam problem by making the content in the email a little dynamic.. Dear so and so, blah blah and in the Subject: Grex registration information for account blah.
resp:38 See steps 4 and 5 in resp:37. I really doubt the spam problem is much of a concern, to be honest.
rofl, so we keep the existing 'validation/validate' process with all it's bureaucracy and we remove a few questions from newuser but we then create a "new email process" <g> (which will suck up more time! with the user having to start a browser and login to yahoo vs taking a few additional seconds answering questions in a SSH/telnet session he already has open) ---- I was thinking along the lines of a no "validation/resh process". Just newuser-with-emailID-request, and password mailed to user and direct access to bash once he recieves his password :) oh well..
Sometimes big reforms require small changes be implemented first, veek.
resp:40 I'm sorry, veek, but you appear to have a very, very small-system mindset. History has shown that we can't just give shell access to Grex. It sucks, but there it is. Are you going to clean up after the Chad's of the world? No. Odds are good that I'm going to be the one who cleans up the messes. In that context, I am *so* unconcerned about someone having to take a few extra *seconds* to check their email to get a password. If we had a web pages that didn't look like they dated from 1994, maybe we'd have more users for this to be an issue. But we don't, and it's not. Let's work on things that are important, like getting the web pages up to date, and then we can start worrying about this stuff.
i;m glad cross is redoing newuser ... miy comment was historical. the futeur wiell be differnet... and if newuewr creates NO passwed for the new logins ... doenslt that open the flooldgarttes? charlie woueild object?
resp:43 I don't understand. Newuser *does* create a password for the user. Who's charlie?
I think you are moving in the right direction, cross. I only wish I could be more useful in the endeavour.
It's helpful to show support, Joe. Thanks!
re 45 ... what gelinas said. re 43 ... ummm, newuser process prompts new-loginid to create a passwd. then why email that pasaswd to new-logoind's alt email addrs? or does the newuwer process wipe out new-logoind's self-created passwd, assign a new passwd and then email that onwe ? as of now, i can see every bad reason to email passwds and no good ones. charlie == charlie root ... from whom we (both??) eget daily emails. eh?
resp:43 Are you talking about the captcha? That's not the user's password.
putty now has a capthca ???? i;ll have to look at teh web version again.
I like the email and captcha features in pnewuser. They're definitely in line with common practice nowadays. Hm, a while back I think I said I was going to post suggestions on what newuser should say in its dialog with the user. Well, I'm on vacation now so that's been pushed back a bit, but I'll try to get on it once I'm home. Speaking of dialog, one of the features of the Marcus Watts newuser was that messages newuser put out were stored in plain text files editable by non-programmers and read by the program at runtime. That's a nice configurability feature. I realize that pnewuser is written in Perl, so that's less of an issue, but I think it would be desirable to be able to configure pnewuser's messages without touching the source code.
I went through the current command line newuser the other day, and saw the captcha feature, too (it looks like figlet lettering). The email feature worked nicely. It gave me the temporary password and told how to log in via ssh, which is a good thing. When I used the password to log in, it immediately had me change it so the user gets to use their desired password (also a good thing). What I had trouble finding, though I may have missed it in all the text that flowed by, was how to get validated. That probably should be part of the resh allowed commands list so that users will find it right away, and part of the instructions when you log in if you are a resh user. Again, I may have missed it, but it wasn't immediately obvious to me.
is the src available for viewing? we could modify it to make sure users understand the risks.. seen that in eclipse.cs.pdx.edu:7680, it's a MUD. They ask the users a lot of questions that they have to get right, before they are allowed into the main area. eg: Dear user, is it safe for you to use the same password to signin to Grex, that you would use at your bank web-site? and he would have to answer no.. stuff like that given the privacy issues we now face.. it would give us a bit of leeway.
I too tested the command line new user recently and liked it a lot.
resp:52 nm found it
I am typing on my phone, so excuse the brevity. All the text is still in text files. Source is in subvversion. It probably needs a soak.
i am -elated- taht newuser text&html have had the cross-soak applied. that it took this much rancor to get there .. well, someitmes it does. tnx cross & testers.
Web newuser is still broke.
But on our collective list to get fixed Real Soon Now.
True dat.
jsut di d the web thing this time/date:
Error in Account Creation
Your application for an account on Grex has not been processed due to a system
problem.
* Could not access directory /usr/noton/nu/
Sorry.
however i did notice this selectable option:
Privacy: Who may see the information in
this section of the form?
All users.
Grex staff
only.
validate necessitates, sometimes, 'grex staff only'.
i;ll try the cli version
he captcha -is- case sensitive ... that needs to be -clear-.
re 57 ... oops didin;t see that .. my bad.
resp:61 That has NOTHING to do with validation. That's just managing a user's expectations so that they understand that staff *can* read their files; that doesn't mean that staff *should*.
sounds like the issue is that too many staffers have root access. Change the root pw and declare that one, and only one person, has that access. Designate one person the root staffer. This eliminates issues like what was being discussed with TS. Most staff work doesn't require root does it?
No, it does not. But it's useful to have multiple people with root. The issue is what to do when that access to abused.
No the issue is whether the usefulness of having multiple staffers with root outweighs what to do when that access is abused. I want to know if Cross would accept root access being limited across the board, including possibly himself, as opposed to banning staffer he doesn't like.
Or better yet, if Cross is so concerned with TS having root access, would he as a trade off, be willing to agree to give up his own root access in exchange for TS losing his? If he were willing to do that, it would lend more credence to his claims.
Richaqrd, Dan needs root because he is the primary system admin.
This response has been erased.
re #69 who made him the primary system admin? I thought staff acted as an ensemble. It seems to me that grex has gotten into problems in the past when there have been attempts to get one person to do too much, to unofficially designate someone a 'primary system admin'. Look at what happened with STeve last year when Grex was down. He was the only staff trying to fix the box and with other staff willing to let him do everything, it probably became too aggravating. He doesn't even post much anymore. Besides Cross is in New York, he has no physical proximity to the hardware so if there was a 'primary system admin' it logically shouldn't be him anyway.
It's not an appointment, Richard. It's a statement of fact. Answer me one question: who has been doing the work of late?
re resp:71: I made him the primary sysadmin. I had the position to do so because I fit into a position between those with power and influence (Board members, staffers, paid members) and those with no interest or ability to decide. I am the average user, and can represent both types of Grexers, so I made the appointment. TS, can you please make sure it shows up in his paycheck? Thank you. Dan, it's official, you can use it in your signature if you like. Also, did you send STeve the customary bonus for his past contributions?
I move to add another zero to Dan's paycheck.
No voting. I've already decided that. Due to budgetary restrictions, we will only be replacing one 0 with another this year.
Times are tough.
Okay I say that the board vote to sell the corporation to JEP for a dollar at the next meeting. Then the board can disband completely. JEP makes all decisions anyway so selling him the corporation would formalize his role as Secretary General, Dictator or King of Grex. The staff already operates at his discretion anyway apparently :)
re #77 And once JEP is formally the owner/dictator of the corporation, he can disband the staff except for Cross and formalize his designation of Cross as primary staffer. Then JEP can order Grex taken offline for a day, get the box out of provide.net, ship it UPS to Cross in New York and let him set it up at his place. Its obvious, at least in JEP's mind, that no other staffers besides Cross really want to do any work anyway. JEP will then be Truman to Cross's McArthur. :)
The funny thing is, it'd probably be the best thing that ever happened to Grex. :P
fwiw ... i am still awaiting my new passwd to ve emmaild to me. ain;t here yetr. cli newuser.
resp:78 My name is Dan; my last name is Cross, but I don't really appreciate it when people refer to me as Cross. resp:80 Sounds like you entered an incorrect email address. Also, check your spam filter.
I'm not a dictator. I just occupied a position at a juxtaposition where everyone distrusted me equally, so I made Dan the sysop. The Board can rescind my position easily, by making any non-anonymous vote regarding me. (But he's still the sysop.)
re 80 ... passwd was emailed/sent right on time .. however, only becaues iscan my spam folder was i able to retreive the damn thing. also, re 81 ... i have no filters on spam 'cept viagra, which i don;t need. .. thinkin gabout adding pfizer though ...
about stuff: for the record, this is on the webnewuwer: Privacy: Who may see the information in this section of the form? All users. Grex staff only. ---------------------- where it prpperly belongs and is the default, as it should be. and there is this as well: Personal Information The rest of this form asks you for various personal information. It's a nice way to let other Grex users know a little bit about you. If you choose, it can be kept private so only the system administrators will be able see it. validatoin, in teh future, may or nay not necessitate "admin;s ability" which i think is the 'to be' general stance if not already in place.
Since we don't have a revised web newuser yet, the web newuser page has not been updated to reflect how it will operate.
You have several choices: