Re: ypbind not registering with rpcbind on SL7
On 08/01/15 02:26, Konstantin Olchanski wrote:
On Wed, Jan 07, 2015 at 05:27:32PM -0700, Stephen John Smoogen wrote:
On 7 January 2015 at 17:06, Konstantin Olchanski olcha...@triumf.ca wrote:
[...snip...]
And I expect that you had at that point still stories from people saying
NIS broke everything when it went down and we should just use some homebrew
kit (or worse yet.. add each user by hand because lord how are you going to
know it got done.)
Yes, nis broke everything. But this went away since we install secondary
NIS servers
on every critical machine - as long as local ypserv and local ypbind stay up,
no problems with NIS, even survives network outages (alsmost, DNS outages
still cause problems).
Yes, add each user by hand, just happened on one of the systems I built,
because local admins cannot figure out NIS and because ypbind keeps dying
on that machine. Not that adding the user manually did any good, without
ypbind
they lose access to the auto-mounted home directory for that user.
And these things are *exactly* what IPA can provide an *easy* user
interface for. If you would really look at it, instead of shooting it
down. Local admins just need to run *one* *single* command as root
(ipa-client-install), and the system is configured and is ready for use.
This single commands configures everything and the options
ipa-client-install take shouldn't make you able to shoot yourself in the
foot, unless you really do it on purpose - and you would know in advance
that it would be stupid.
With this experience - people cannot figure out service ypbind restart
and vi /etc/auto.home; make -C /var/yp - I am not putting out anything as
complex as LDAP, Kerberos, Web based administration, etc.
If people can't figure out that ypbind needs to be started or manually
modify /etc/auto.home and updating it with a make command, then I'd say
NIS is too complex too. Then doing the single ipa-client-install *is*
simpler from their perspective.
You seem not to have grasped that IPA doesn't need users to understand
LDAP or Kerberos at all. IPA does all that for you, and all you need to
understand is to run ipa-client-install on the clients. And the IPA
admin provides a lot of safe-guards, helping you not doing anything stupid.
Since I deployed FreeIPA on two networks, I have only _once_ needed to
use an LDIF file to update the 389-DS configuration on the servers to
workaround a bug in the replication (which, btw, should be fixed in
newer upstream versions of 389-DS). And that is the only time I needed
to touch more lower-level LDAP pieces. And _not_ _once_ have I needed
to touch kadmin tools.
[...snip]
Yes, so true. And yet, in 10 years, no viable replacement, other than
the light weight 800 poud gorilla of identity management product.
Do you mean server or client side? On my server at home (HP Microserver
with AMD N54L! That's a fairly low performance CPU) the IPA server
(389DS, Kerberos daemons, Apache httpd) spends roughly 130MB of RAM
today. The SSSD daemon which clients needs uses something like 40MB.
And neither server nor client processes uses much CPU time. On todays
computers (even on embedded), the SSSD RAM usage won't be a problem.
Yes, it might be far more than your ypbind setup. But IPA provides a
far more robust and feature rich implementation with far better security
which is better suited for the 21th century.
As Stephen said earlier, it's your shop and you'll do it how you want it
on your site. But please stop spreading FUD about IPA being such
gigantic monster. Such FUD was what kept me away from IPA for far too
long, and I was incredibly surprised to see how easy it was to setup and
configure, and how little intrusive the setup really was. I instantly
regretted not having done this earlier.
Yes, the documentation suggests that IPA servers should provide DNS and
NTP services as well. Those are *optional*. In fact the default
installation of FreeIPA servers *does not* include DNS, you must add
--setup-dns to do get that. NTP can also be ignored by passing --no-ntp
to ipa-{client,server}-install. But, yes, it is *recommended* to
provide these services to your domain.
I tried the IPA DNS setup at home, where I already had my own BIND
server running. I decided to only try DNS on the sub-domain for IPA
clients. It took me less than a week before I had migrated the
complete DNS to IPA, because it just made my life so much easier -
despite I didn't have to do this at all. So now my old DNS server is
mostly a slave DNS to my IPA server instead - and the rest of my boxes
(even DHCP server) didn't need to be updated. At home, things are
definitely in a better state now than before.
For NTP, as long as the clocks on all boxes are in sync, there's really
no need to worry about that. But once clocks are more than 5 minutes
(IIRC) out of sync against the IPA server, authentication may fail. I
even think the time scew tolerance is configurable too.
--
RE: ypbind not registering with rpcbind on SL7
“My main concern is that most places I have seen that kept with ypbind get replaced with Active Directory” In fact, we’re in the process of doing that now. We’ve got user logins and groups working well. The next challenge is the automount maps. It’s not a bad thing, in fact it has made our Windows / Linux integration much easier. It’s quite nice to be able to use Putty on Windows and have it pass the Kerberos ticket you logged into Windows with over to the Linux server you’re connecting to. -- James Pulver CLASSE Computer Group Cornell University From: owner-scientific-linux-us...@listserv.fnal.gov [mailto:owner-scientific-linux-us...@listserv.fnal.gov] On Behalf Of Stephen John Smoogen Sent: Wednesday, January 07, 2015 5:22 PM To: scientific-linux-users@fnal.gov Subject: Re: ypbind not registering with rpcbind on SL7 On 7 January 2015 at 14:54, Konstantin Olchanski olcha...@triumf.camailto:olcha...@triumf.ca wrote: Yes, thank you for the references to the Red Hat identity management system. Of course it is based on LDAP, but also it requires use of Kerberos (which we do not have fun with in the AFS/Kerberos environement at CERN), and recommended practice is to have it take over the DNS and NTP services. To me this looks like software designed to manage central IT at IBM (complete with a full staff of professional sysadmins). Too heavy weight (in the number of software components and in the number of books to read) for running small clusters of 5-10 machines managed by non-dedicated non-sysadmin non-IT people. Hehe. I remember when 20 years ago people would say the exact same thing about ypbind over some sort of script set which copied everything with root rcp. Those then got replaced by people who had used ypbind somewhere and were comfortable on it. My main concern is that most places I have seen that kept with ypbind get replaced with Active Directory (which FreeIPA is really trying to give an answer for). But in the end, it is your shop and you will do it however it is needed :). -- Stephen J Smoogen.
Re: ypbind not registering with rpcbind on SL7
Hi guys, if i might add my view onto this matter .. :] I think the LDAP doesn't complicate things - on the contrary, it simplify them. Ofc, the installation and configuration of 389 Directory server (if speaking about RHEL and clones) is definitely much more demanding in know-how compared to YP. But speaking then about day-to-day work, and setting up other things than need authentication, the LDAP is a blessing. Half year ago i helped to do a 'switch' to LDAP for a company (300 users) in mixed env of Windows workstations and servers, Linux workstations and servers. DC was 3.6 samba authenticating windows users and YP for unix /linx users. Then other various systems needing authentication (printers, IM system, zimbra, blackberry server ... maintaining anything user-data related was hell for the IT team. I implemented 389DS with as a authentication backend for Samba and SSSD. And i pointed all other applications / devices that require authentication to LDAP too (printers, openfire server, osticket system, zimbra server etc etc). With the help of smbldap-tools and written scripts i recrunched data, changed needed rights, Samba RIDs and SIDs, Linux UIDs and migrated everything. Since then, no more user-data problems. What i want to say is, YP server, thanks to it's simplicity still has its uses in purely Unix/Linux secured LANs, but such an environment is quite a rarity nowadays. LDAP is the standard these days in both worlds - unix and windows alike. No matter if speaking about windows AD with multimaster replication or about IPA (again with mulstimaster repl) the backend storing user data is still LDAP. cheers, -- *Karel Lang* *Unix/Linux Administration* l...@afd.cz | +420 731 13 40 40 AUFEER DESIGN, s.r.o. | www.aufeerdesign.cz
Re: ypbind not registering with rpcbind on SL7
On Wed, Jan 07, 2015 at 03:21:37PM -0700, Stephen John Smoogen wrote: On 7 January 2015 at 14:54, Konstantin Olchanski olcha...@triumf.ca wrote: Hehe. I remember when 20 years ago people would say the exact same thing about ypbind over some sort of script set which copied everything with root rcp. Those then got replaced by people who had used ypbind somewhere and were comfortable on it. I started in this business in 1992 and our cluster of SGI machines was already based on NIS (from before my time). (I think automount/autofs/amd showed up a little later). But believe it or not, I am seriously considering going back to scp-pushed config files - too many technical problems have accumulated with NIS and with the current software chain nis maintainers-Fedora-RHEL-SL I doubt they will ever be fixed (even if nis maintainers still exist): - ypbind vanished mysteriously (usually during periods of network connectivity loss) - ypbind killed by OOM killer (kill something else, please!). - autofs and rpc.mountd doing negative caching (after pushing new autofs and netgroup maps, these demons have to be restarted on each client machine, or they would not see the added entries). - ypbind does not automatically open holes in the firewall (fixed in SL7?!?) - hard to add non-standard autofs maps (have to edit the Makefile). - probably more. My main concern is that most places I have seen that kept with ypbind get replaced with Active Directory (which FreeIPA is really trying to give an answer for). Not in the DAQ world - makes no sense to run a Windows Activer Directory box just to manage a bunch of (effectively) embedded Linux machines. Plus DAQ usually means unattended operation while Windows (and MacOS) has too many keyboard not found, please press F1 to continue gems and generally assume that there is a human lackey in front of the terminal at all times ready to service any whim (let's reboot now to install these important Windows updates!). -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: ypbind not registering with rpcbind on SL7
On 7 January 2015 at 17:06, Konstantin Olchanski olcha...@triumf.ca wrote: On Wed, Jan 07, 2015 at 03:21:37PM -0700, Stephen John Smoogen wrote: On 7 January 2015 at 14:54, Konstantin Olchanski olcha...@triumf.ca wrote: Hehe. I remember when 20 years ago people would say the exact same thing about ypbind over some sort of script set which copied everything with root rcp. Those then got replaced by people who had used ypbind somewhere and were comfortable on it. I started in this business in 1992 and our cluster of SGI machines was already based on NIS (from before my time). (I think automount/autofs/amd showed up a little later). And I expect that you had at that point still stories from people saying NIS broke everything when it went down and we should just use some homebrew kit (or worse yet.. add each user by hand because lord how are you going to know it got done.) But believe it or not, I am seriously considering going back to scp-pushed config files - too many technical problems have accumulated with NIS and with the current software chain nis maintainers-Fedora-RHEL-SL I doubt they will ever be fixed (even if nis maintainers still exist): NIS has been dead upstream for 10+ years when Sun started pushing NIS+ and then their own LDAP solution afterwords. A lot of large business/.gov/.mil list it as verbotten because of the many security problems it has (password issues usually though various hijacking items can occur). It is mostly still in the distribution because people like us who became admins from 1987-1994 have it in our toolkit and know how to use it. For the scp item.. you might want to look at ansible. It does orchestration over ssh which allows for a lot of bypassing of these items. - ypbind vanished mysteriously (usually during periods of network connectivity loss) - ypbind killed by OOM killer (kill something else, please!). - autofs and rpc.mountd doing negative caching (after pushing new autofs and netgroup maps, these demons have to be restarted on each client machine, or they would not see the added entries). - ypbind does not automatically open holes in the firewall (fixed in SL7?!?) - hard to add non-standard autofs maps (have to edit the Makefile). - probably more. My main concern is that most places I have seen that kept with ypbind get replaced with Active Directory (which FreeIPA is really trying to give an answer for). Not in the DAQ world - makes no sense to run a Windows Activer Directory box just to manage a bunch of (effectively) embedded Linux machines. Plus DAQ usually means unattended operation while Windows (and MacOS) has too many keyboard not found, please press F1 to continue gems and generally assume that there is a human lackey in front of the terminal at all times ready to service any whim (let's reboot now to install these important Windows updates!). Not as much these days... if at all. I actually know some remote data aqcuisition places converted over to windows only with it all automated. It is mostly from 2012 onward, but it is catching up and we may end up dinosaurs faster than we throught. -- Stephen J Smoogen.
Re: ypbind not registering with rpcbind on SL7
Yes, thank you for the references to the Red Hat identity management system. Of course it is based on LDAP, but also it requires use of Kerberos (which we do not have fun with in the AFS/Kerberos environement at CERN), and recommended practice is to have it take over the DNS and NTP services. To me this looks like software designed to manage central IT at IBM (complete with a full staff of professional sysadmins). Too heavy weight (in the number of software components and in the number of books to read) for running small clusters of 5-10 machines managed by non-dedicated non-sysadmin non-IT people. K.O. On Wed, Jan 07, 2015 at 02:39:18PM +0100, David Sommerseth wrote: On 07/01/15 02:38, Konstantin Olchanski wrote: On Wed, Jan 07, 2015 at 01:10:19AM +0100, David Sommerseth wrote: I dare you to try out FreeIPA. (private reply) That's LDAP again. The quick start guide looks simple enough, but only because it does not include the instructions for converting autofs maps into LDAP and does not include instructions for setting up a distributed system with multiple servers for redundancy. Importing autofs maps: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/configuring-maps.html#importing-maps Setting up IPA replication: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/installing-replica.html https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/creating-the-replica.html With SSSD running on the clients, it will access available IPA servers, based on DNS lookups. Important information from the IPA server is also cached by the local SSSD, which ensures you can access the system even though there are connectivity issues. To me it all looks like a lot of learning and a lot of doing just to have something we already have with NIS. If you already have NIS running, the short-term benefit probably won't be that big. However, moving towards IPA gives far more advanced possibilities than what NIS can provide, and in a more secure way than what the NIS protocol can provide. Which can be more beneficial in a more long-term perspective. And then the DAQ systems we build are used by Physics PhDs who can barely understand autofs and NIS, forget about kerberos, LDAP or anything complicated at all. I took RHEL/SL/CentOS/Fedora as a starting point. I don't know anything about DAQ and that wasn't even mentioned in the discussion thread until now. Anyhow, much of the IPA admin interface stuff simplifies much of it through a far more user friendly webUI for normal day-to-day tasks. And you don't really need to understand the technical details that much to grasp the webUI. So I would say that IPA helps you to do correct configurations more easily and quicker. Once things have been setup, users mostly don't need to care much at all and the admins can have better control in an easier way. So I still encourage you to take it for a test-drive, to see what it can do. But I agree, when you have a running NIS setup, looking at IPA is more a long-term project than something you need to do right now. David S. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: ypbind not registering with rpcbind on SL7
On 7 January 2015 at 14:54, Konstantin Olchanski olcha...@triumf.ca wrote: Yes, thank you for the references to the Red Hat identity management system. Of course it is based on LDAP, but also it requires use of Kerberos (which we do not have fun with in the AFS/Kerberos environement at CERN), and recommended practice is to have it take over the DNS and NTP services. To me this looks like software designed to manage central IT at IBM (complete with a full staff of professional sysadmins). Too heavy weight (in the number of software components and in the number of books to read) for running small clusters of 5-10 machines managed by non-dedicated non-sysadmin non-IT people. Hehe. I remember when 20 years ago people would say the exact same thing about ypbind over some sort of script set which copied everything with root rcp. Those then got replaced by people who had used ypbind somewhere and were comfortable on it. My main concern is that most places I have seen that kept with ypbind get replaced with Active Directory (which FreeIPA is really trying to give an answer for). But in the end, it is your shop and you will do it however it is needed :). -- Stephen J Smoogen.
Re: ypbind not registering with rpcbind on SL7
On Wed, Jan 07, 2015 at 05:27:32PM -0700, Stephen John Smoogen wrote: On 7 January 2015 at 17:06, Konstantin Olchanski olcha...@triumf.ca wrote: I started in this business in 1992 and our cluster of SGI machines was already based on NIS (from before my time). (I think automount/autofs/amd showed up a little later). And I expect that you had at that point still stories from people saying NIS broke everything when it went down and we should just use some homebrew kit (or worse yet.. add each user by hand because lord how are you going to know it got done.) Yes, nis broke everything. But this went away since we install secondary NIS servers on every critical machine - as long as local ypserv and local ypbind stay up, no problems with NIS, even survives network outages (alsmost, DNS outages still cause problems). Yes, add each user by hand, just happened on one of the systems I built, because local admins cannot figure out NIS and because ypbind keeps dying on that machine. Not that adding the user manually did any good, without ypbind they lose access to the auto-mounted home directory for that user. With this experience - people cannot figure out service ypbind restart and vi /etc/auto.home; make -C /var/yp - I am not putting out anything as complex as LDAP, Kerberos, Web based administration, etc. But believe it or not, I am seriously considering going back to scp-pushed config files - too many technical problems have accumulated with NIS and with the current software chain nis maintainers-Fedora-RHEL-SL I doubt they will ever be fixed (even if nis maintainers still exist): NIS has been dead upstream for 10+ years when Sun started pushing NIS+ and then their own LDAP solution afterwords. A lot of large business/.gov/.mil list it as verbotten because of the many security problems it has (password issues usually though various hijacking items can occur). It is mostly still in the distribution because people like us who became admins from 1987-1994 have it in our toolkit and know how to use it. Yes, so true. And yet, in 10 years, no viable replacement, other than the light weight 800 poud gorilla of identity management product. For the scp item.. you might want to look at ansible. It does orchestration over ssh which allows for a lot of bypassing of these items. Yes, thanks. Not as much these days... if at all. I actually know some remote data aqcuisition places converted over to windows only with it all automated. It is mostly from 2012 onward, but it is catching up and we may end up dinosaurs faster than we throught. Today's game is all in embedded computing - FPGA, embedded ARM, low power devices - where x86 stuff and Windows are completely uncompetitive. (good. *I* am not worried). -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
