<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><blockquote type="cite">I don't think I've ever flamed anyone in my life, but now I believe I<br>have to.<br><br>Sadly, it seems like this is a recurring theme with you. I've seen<br>literally DOZENS of posts from you in the archives and through google<br>and in every single one of them there IS NOT a shred of helpful advice<br>except to RTFM.<br></blockquote><div><br></div>There's usually a good reason for Alan's terse answers.<div><br><blockquote type="cite">The vaunted documentation is just about the worst I've ever seen. It<br>goes in circles:<br><br>From modules/passwd:<br><br>> # An example configuration for using /etc/passwd. # # We do NOT<br>> recommend using the configuration below. See the "unix" # module,<br>> or the "pam" module for a cleaner way to get system passwords. #<br>> Using this configuration means that the server will find *only*<br>> those # passwords which are in /etc/passwd, and will *ignore* all<br>> of the # passwords in NIS, LDAP, etc. #<br><br>From modules/unix<br></blockquote><div><br></div><div>Is the reason for not recommending the use of the passwd module </div><div>applicable here?</div><div><br></div>No.<div><br></div><div>The documentation assumes that you are able to read, interpret,</div><div>and make your own decisions about the validity of information.</div><div><br><blockquote type="cite">> unix { # As of 1.1.0, the Unix module no longer reads, # or<br>> caches /etc/passwd, /etc/shadow, or /etc/group. # If you wish to<br>> cache those files, see the passwd # module.<br></blockquote><div><br></div>So use the passwd module.<br><br><blockquote type="cite">From radiusd.conf:<br>> # On systems with shadow passwords, you might have to set 'group =<br>> shadow' # for the server to be able to read the shadow password<br>> file. If you can # authenticate users while in debug mode, but<br>> not in daemon mode, it may be # that the debugging mode server is<br>> running as a user that can read the # shadow info, and the user<br>> listed below can not.<br><br>(FWIW, this documentation is beyond incomprehensible. The 'group =<br>shadow' is not about using the group 'shadow' to access /etc/shadow<br>it's changing the group on /etc/shadow to 'radiusd'.)<br></blockquote><div><br></div>No. It's about setting the group the FreeRADIUS daemon runs as.<br><div><br></div><div>The FreeRADIUS daemon does not switch GID or UID when running in debug</div><div>mode, it continues with the GID and UID of the user which invoked it.</div><div><br></div><div>That's what the documentation is talking about.</div><div><br></div><blockquote type="cite">>>><br>>>> And setting "a+rw" on /etc/passwd and /etc/shadow is probaby<br>>>> the single worst thing you can do to your system.</blockquote><div><br></div><div>Yes, setting a+rw would be completely idiotic, if you really don't</div><div>understand why, you should probably not have permission to make </div><div>such a change.</div><br><blockquote type="cite"> EVER.<br>>>> Rather than doing that, read raddb/radiusd.conf, it talks about<br>>>> issues with reading /etc/shadow, and describes suggested fixes<br>>>> won't<br>>> destroy your<br>>>> system.<br>>>><br>>>> Honestly, I don't understand why it's so hard to read the<br>>>> configuration files.<br></blockquote><div><br></div>Agreed.</div><div><br><blockquote type="cite">>>><br>>>> Alan DeKok. -<br><br>Radiusd.conf DOES NOT talk about issues with reading /etc/shadow.<br>ANYWHERE. PERIOD.<br></blockquote><div><br></div>Because radiusd.conf is the main configuration file for the server,</div><div>why would it be cluttered with module specific configuration snippets</div><div>or advice...</div><div><br></div><div><br><blockquote type="cite"> And I've NEVER dealt with a more unprofessional and unhelpful<br>mailing list as I have with this list. </blockquote><blockquote type="cite">What should be a relatively<br>'simple' solution is anything but with this list. I'm no noob working<br>with linux/unix and text configuration files, and yet I feel FARTHER<br>away from an answer that I did before I started.<br></blockquote><div><br></div><blockquote type="cite">And due to that 'take two steps forward and half-dozen back', I've<br>made it clear to my boss that FreeRADIUS, while it may work just fine,<br>will be impossible to manage due to the horrible documentation and<br>utter lack of help on the lists. </blockquote><div><br></div><div>An excerpt from the Fedora list:</div><div><br></div></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><a href="http://marc.info/?l=fedora-list&m=139426697003081&w=2">http://marc.info/?l=fedora-list&m=139426697003081&w=2</a></div></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><div><div><div>> On 03/06/14 20:22, David Beveridge wrote:</div></div></div></div><div><div><div>></div></div></div><div><div><div>>></div></div></div><div><div><div>>> You don't need to lie, or make stuff up, just explain that it IS</div></div></div><div><div><div>>> possible, BUT just not within the timeframe and budget requested.</div></div></div><div><div><div>>></div></div></div><div><div><div>></div></div></div><div><div><div>> Thing is, based on my searching, getting FreeRADIUS to work with NIS</div></div></div><div><div><div>> isn't possible. At least I've found no documentation on how to make</div></div></div><div><div><div>> it work. There's tons on getting it to work with LDAP, but not NIS.</div></div></div><div><div><div>> Which is the reason for my OP.</div></div></div><div><div><div>></div></div></div><div><div><div>Except for the fact that I already posted here how you can do it...</div></div></div><div><div><div><br></div></div></div><div><div><div>eg: Freeradius supports perl module and perl can do NIS Auth.</div></div></div><div><div><div><br></div></div></div><div><div><div>check out example.pl and then do a google search for "perl NIS"</div></div></div></blockquote><div><div><div><br></div></div><div>Looks like you're having similar difficulties over there too.</div></div><div><br></div><div>---<br><div>Arran Cudbard-Bell <<a href="mailto:a.cudbardb@freeradius.org">a.cudbardb@freeradius.org</a>><br>FreeRADIUS Development Team<br><br>FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2<br></div><br></div></body></html>