On Tue, 8 Nov 2011, Chuck Swiger wrote: > Hi-- > > On Nov 8, 2011, at 4:32 PM, Dan The Man wrote: >> On Tue, 8 Nov 2011, Chuck Swiger wrote: >>> On Nov 8, 2011, at 3:47 PM, Dan The Man wrote: >>>> In the daily cron "Daily run output" email always get the following: >>>> >>>> Verifying group file syntax: >>>> chkgrp: /etc/group: line 3: '_at_' invalid character >>> >>> chkgrp expects group names to consist of characters in isalnum(). >> >> K so thats a simple fix where it does that check. > > usr.sbin/chkgrp/chkgrp.c, line ~117: > > for (cp = f[0] ; *cp ; cp++) { > if (!isalnum(*cp) && *cp != '.' && *cp != '_' && *cp != '-' && > (cp > f[0] || *cp != '+')) { > warnx("%s: line %d: '%c' invalid character", gfn, n, *cp); > e++; > } > } > > Add a "&& *cp != '_at_'" clause to the if statement. It doesn't bother me enough to have to modify the if statement on every new buildworld(which I seem to be doing alot of lately), honestly that one email login in the group file is only email login that will ever touch an /etc file, rest is in database. I wouldn't personally add any email type logins to a base system directly. > >>>> Could we modify system to support email addresses as usernames. >>> >>> Sure, that's why FreeBSD comes with source code. >>> You can modify anything you like. :-) >>> >>> However, if you want to use a domain-aware login mechanism, Kerberos is in the base system, and SASL and LDAP are available in ports. You're not going to break anything allowing "_at_" into the list of characters which pw(8) likes, but the flatfile passwd and group files are not hierarchical the way domain-aware network identity systems are. >>> >>> A secondary issue is that there is rarely a one-to-one relationship between email addresses and users; many email addresses are aliases which expand either to a different username, or even to multiple users. >> >> Wish you would elaborate abit more here, what I have found is email addresses tend to make the best usernames, people can remember them :) >> They are unique, and you solve 2 problems right away: >> a) they can actually remember their username >> b) they aren't having to pick through a million different taken usernames >> they have to pick on their own, which is frusterating way people often do signups. > > If you've got a database of millions of users, you're definitely functioning in a different realm than what /etc/passwd and /etc/group were designed for. :-) > Well thats the idea right, unlimited growth but a central place to store everything for scalability purposes. Of course if you actually tried to login 1 million people to same machine, I am sure you would kill the I/O instantly :) Basically approach I've been taking is central database that stores all users, any machine can be configured to not allow logins from anyone in database by just removing them from /etc/nsswitch.conf. You can control which of those million users can login to a certain machine by simply modifying the select statement to the database in the nss-database config file...all in all these changes take 2 seconds to change and makes things quite easy. > Anyway, the idea is that you should be able to define multiple hierarchy levels for your identity database, which NIS+, NetInfo, Kerberos, and LDAP (kinda-sorta) can support. This lets you define an identity either at the root level, which is visible everywhere, or in subdomains from root, which means the identity is valid only within that subdomain but not in other subdomains-- and "johndoe" in one subdomain can be entirely different than "johndoe" in some other domain. (If you want "johndoe" the same everywhere, you'd define it at root instead.) > > That's just a bare-bones explanation, but a more complete one would likely approach book-length. :-) I'm sure it would make an interesting read, I try not to concern myself to much with mechanisms that would likely to take to long to respond if there were millions of users, working directly with mysql/postgres/oracle from getgo i think is safe. Think its almost like an analogy to where you started off building your network code using something simple like select() then you kicked yourself in the ass after for not having used epoll() on linux or kqueue() on freebsd in an eventloop as your application got to many connections. I do like your idea in a small office type setting though, definately wouldn't mind trying something like that here at home so I had a central way for all these development machines I got lieing around to have some central login place. Found this an interesting read last night: http://www.mrp3.com/windows-to-unix-samba.html might be abit dated... Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: Dan_at_SunSaturn.com > >>> You might not care, but don't be surprised if you find that folks aren't willing to adopt this change back into FreeBSD-- I've seen a few people wanting to increase MAXLOGNAME since 2003 or so. >> >> I've talked to many sys admins as well, that are all modifying the code to the kernel for a decade now on every new make buildworld, would be nice to see it mainstream. > > Sure, you can find examples or counterexamples if you look for 'em... > > Regards, > -- > -Chuck > >Received on Wed Nov 09 2011 - 00:28:26 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:20 UTC