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: '@' 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 != '@'" 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 "@" 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: d...@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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
