fastbugs: yum-autoupdate package broken?
Greetings, Is anyone else having this issue? A bunch of my servers sent me emails this morning about the yum-autoupdate package. Should I just be patient and wait for a while or is there an actual issue? Thanks. ~Stack~ # yum clean all yum update Loaded plugins: security Cleaning repos: epel sl sl-fastbugs sl-security Cleaning up Everything Loaded plugins: security Setting up Update Process epel/metalink | 14 kB 00:00 epel | 4.4 kB 00:00 epel/primary_db | 6.4 MB 00:01 sl | 3.6 kB 00:00 sl/primary_db | 4.3 MB 00:03 sl-fastbugs | 3.0 kB 00:00 sl-fastbugs/primary_db | 256 kB 00:00 sl-security | 2.9 kB 00:00 sl-security/primary_db | 1.2 MB 00:00 Resolving Dependencies -- Running transaction check --- Package yum-autoupdate.noarch 5:2-6.3 will be updated --- Package yum-autoupdate.noarch 5:2-6.6 will be an update -- Finished Dependency Resolution Dependencies Resolved = Package Arch Version Repository Size = Updating: yum-autoupdatenoarch 5:2-6.6 sl-fastbugs 27 k Transaction Summary = Upgrade 1 Package(s) Total download size: 27 k Is this ok [y/N]: y Downloading Packages: http://ftp.scientificlinux.org/linux/scientific/6.6/x86_64/updates/fastbugs/yum-autoupdate-2-6.6.noarch.rpm: [Errno 14] PYCURL ERROR 22 - The requested URL returned error: 404 Not Found Trying other mirror. http://ftp1.scientificlinux.org/linux/scientific/6.6/x86_64/updates/fastbugs/yum-autoupdate-2-6.6.noarch.rpm: [Errno 14] PYCURL ERROR 22 - The requested URL returned error: 404 Not Found Trying other mirror. http://ftp2.scientificlinux.org/linux/scientific/6.6/x86_64/updates/fastbugs/yum-autoupdate-2-6.6.noarch.rpm: [Errno 14] PYCURL ERROR 22 - The requested URL returned error: 404 Not Found Trying other mirror. ftp://ftp.scientificlinux.org/linux/scientific/6.6/x86_64/updates/fastbugs/yum-autoupdate-2-6.6.noarch.rpm: [Errno 14] PYCURL ERROR 19 - Given file does not exist Trying other mirror. Error Downloading Packages: 5:yum-autoupdate-2-6.6.noarch: failure: yum-autoupdate-2-6.6.noarch.rpm from sl-fastbugs: [Errno 256] No more mirrors to try. signature.asc Description: OpenPGP digital signature
gdbm update broke my yp make
Hi With gdbm-1.8.0-36.el6.x86_64 in Scientific Linux release 6.6 (Carbon) my yp make works fine: # make gmake[1]: Entering directory `xxx' Updating auto.home... Updating auto.data... Updating auto.scratch... gmake[1]: Leaving directory `xxx' With the update that came in this morning from fastbugs, gdbm-1.8.0-37.el6.x86_64, I now get: # make gmake[1]: Entering directory `xxx' Updating auto.home... makedbm: dbm_store: Success gmake[1]: [auto.home] Error 1 (ignored) Updating auto.data... makedbm: dbm_store: Success gmake[1]: [auto.data] Error 1 (ignored) Updating auto.scratch... makedbm: dbm_store: Success gmake[1]: [auto.scratch] Error 1 (ignored) gmake[1]: Leaving directory `xxx' and the yp maps are not updated. Does anyone else see this or is it something pathological to my setup? By downgrading to the -36 package I can restore the yp make to working again. Thanks Roderick Johnstone
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: gdbm update broke my yp make
On Wed, Jan 07, 2015 at 02:35:46PM +, Roderick Johnstone wrote: With the update that came in this morning from fastbugs, gdbm-1.8.0-37.el6.x86_64, I now get: # make gmake[1]: Entering directory `xxx' Updating auto.home... makedbm: dbm_store: Success gmake[1]: [auto.home] Error 1 (ignored) By downgrading to the -36 package I can restore the yp make to working again. Confirmed. NIS becomes broken all right. And there is more breakage, see other comments here: https://bugzilla.redhat.com/show_bug.cgi?id=629640#c31 -- 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
