[CentOS-announce] CEBA-2011:1357 CentOS 5 x86_64 nmap FASTTRACK Update
CentOS Errata and Bugfix Advisory 2011:1357
Upstream details at : http://rhn.redhat.com/errata/RHBA-2011-1357.html
The following updated files have been uploaded and are currently
syncing to the mirrors: ( md5sum Filename )
x86_64:
cc9136755776e02e074831154a8c681e nmap-4.11-2.x86_64.rpm
65ce9a21b945c42a7e95cb54f3d09e42 nmap-frontend-4.11-2.x86_64.rpm
Source:
27036bc09971149699ae99614d12d124 nmap-4.11-2.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
___
CentOS-announce mailing list
CentOS-announce@centos.org
http://lists.centos.org/mailman/listinfo/centos-announce
[CentOS-announce] CEBA-2011:1357 CentOS 5 i386 nmap FASTTRACK Update
CentOS Errata and Bugfix Advisory 2011:1357
Upstream details at : http://rhn.redhat.com/errata/RHBA-2011-1357.html
The following updated files have been uploaded and are currently
syncing to the mirrors: ( md5sum Filename )
i386:
524f68792dc4d42e8438e30459103eb6 nmap-4.11-2.i386.rpm
1eba5a37fcc1cc512dce6a427773d704 nmap-frontend-4.11-2.i386.rpm
Source:
27036bc09971149699ae99614d12d124 nmap-4.11-2.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
___
CentOS-announce mailing list
CentOS-announce@centos.org
http://lists.centos.org/mailman/listinfo/centos-announce
[CentOS-announce] CESA-2011:1359 Moderate CentOS 5 i386 xorg-x11-server Update
CentOS Errata and Security Advisory 2011:1359 Moderate
Upstream details at : http://rhn.redhat.com/errata/RHSA-2011-1359.html
The following updated files have been uploaded and are currently
syncing to the mirrors: ( md5sum Filename )
i386:
566dfe5253d4216246d79e7bc0386da3
xorg-x11-server-sdk-1.1.1-48.76.el5_7.5.i386.rpm
9a2a7fdcb5cab116bcb958c64531688e
xorg-x11-server-Xdmx-1.1.1-48.76.el5_7.5.i386.rpm
471b67cd327f28c2eb358b648c2e21cb
xorg-x11-server-Xephyr-1.1.1-48.76.el5_7.5.i386.rpm
de4563689fa5b1729c24ac65ec5c7b85
xorg-x11-server-Xnest-1.1.1-48.76.el5_7.5.i386.rpm
930dafaf623b248b5d6cc2380e6ef6bb
xorg-x11-server-Xorg-1.1.1-48.76.el5_7.5.i386.rpm
c5eb7da9ca50887619d0bddeaec80f67
xorg-x11-server-Xvfb-1.1.1-48.76.el5_7.5.i386.rpm
05fdb90676ca14cbbe586c65d4838c62
xorg-x11-server-Xvnc-source-1.1.1-48.76.el5_7.5.i386.rpm
Source:
3550e4ad86c9faa0220613fed930faaf xorg-x11-server-1.1.1-48.76.el5_7.5.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
___
CentOS-announce mailing list
CentOS-announce@centos.org
http://lists.centos.org/mailman/listinfo/centos-announce
Re: [CentOS-virt] Should I switch and if so what is the procedure
Its seems that I should switch then. I have 2 servers using Xen. What is the procedure to conver them? Is there procedure I should use. I have to use the same boxes I can not export vm's. On Wed, Oct 5, 2011 at 7:46 PM, Dennis Jacobfeuerborn denni...@conversis.de wrote: On 10/05/2011 06:16 PM, Ed Heron wrote: On Wed, 2011-10-05 at 10:55 -0400, Rich wrote: Since the Xen and Linux kernel people have finally made peace and Xen is going to be included with the kernel, should I keep using the Xen virtual server with Centos or should I switch to KVM? I am running Centos 5.7 now. I guess the real question is can I still use Xen with Centos 6? The support end of life for CentOS 5 is listed as March 31, 2014 ( http://wiki.centos.org/FAQ/General#head-fe8a0be91ee3e7dea812e8694491e1dde5b75e6d). There isn't any pressure, at this point, to convert your VM hosts to CentOS 6 unless there is some feature you require. I doubt RH will add XEN support to RHEL 6. They don't like to add functionality to an existing product. We can hope they bring XEN back in RHEL 7. While Xen will probably return in RHEL 7 simply because it is part of the upstream kernel now I doubt it will be officially supported by Red Hat. Between buying Qumranet (http://www.redhat.com/promo/qumranet/) and now Gluster (https://www.redhat.com/promo/storage/) it is clear that Red Hat aims to become a provider of a complete independent virtualization stack and is unlikely to support competing products directly. The question is what does Xen offer that KVM cannot provide? Looking at the slides of the KVM Forum 2011 (http://www.linux-kvm.org/page/KVM_Forum_2011 ) there seem to be many interesting improvements in the pipeline so at some point the question really is why hold on to Xen at all when there is not real reason to? Regards, Dennis ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-virt] Should I switch and if so what is the procedure
On 10/06/2011 12:58 PM, Rich wrote: Its seems that I should switch then. I have 2 servers using Xen. What is the procedure to conver them? Is there procedure I should use. I have to use the same boxes I can not export vm's. I've used the following links to migrate our office servers: http://www.gloudemans.info/migrate-paravirtualized-xen-to-kvm-under-rhel/ http://www.cyberciti.biz/faq/troubleshooting-kvm-virtualization-problem-with-log-files/ http://www.cyberciti.biz/faq/rhel-linux-kvm-virtualization-bridged-networking-with-libvirt/ In any case, be cautious, make backups and don't do this at 3:00 AM. Peter On Wed, Oct 5, 2011 at 7:46 PM, Dennis Jacobfeuerborn denni...@conversis.de mailto:denni...@conversis.de wrote: On 10/05/2011 06:16 PM, Ed Heron wrote: On Wed, 2011-10-05 at 10:55 -0400, Rich wrote: Since the Xen and Linux kernel people have finally made peace and Xen is going to be included with the kernel, should I keep using the Xen virtual server with Centos or should I switch to KVM? I am running Centos 5.7 now. I guess the real question is can I still use Xen with Centos 6? The support end of life for CentOS 5 is listed as March 31, 2014 (http://wiki.centos.org/FAQ/General#head-fe8a0be91ee3e7dea812e8694491e1dde5b75e6d). There isn't any pressure, at this point, to convert your VM hosts to CentOS 6 unless there is some feature you require. I doubt RH will add XEN support to RHEL 6. They don't like to add functionality to an existing product. We can hope they bring XEN back in RHEL 7. While Xen will probably return in RHEL 7 simply because it is part of the upstream kernel now I doubt it will be officially supported by Red Hat. Between buying Qumranet (http://www.redhat.com/promo/qumranet/) and now Gluster (https://www.redhat.com/promo/storage/) it is clear that Red Hat aims to become a provider of a complete independent virtualization stack and is unlikely to support competing products directly. The question is what does Xen offer that KVM cannot provide? Looking at the slides of the KVM Forum 2011 (http://www.linux-kvm.org/page/KVM_Forum_2011) there seem to be many interesting improvements in the pipeline so at some point the question really is why hold on to Xen at all when there is not real reason to? Regards, Dennis ___ CentOS-virt mailing list CentOS-virt@centos.org mailto:CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-virt] Should I switch and if so what is the procedure
On Wed, Oct 5, 2011 at 6:46 PM, Dennis Jacobfeuerborn denni...@conversis.de wrote: On 10/05/2011 06:16 PM, Ed Heron wrote: On Wed, 2011-10-05 at 10:55 -0400, Rich wrote: Since the Xen and Linux kernel people have finally made peace and Xen is going to be included with the kernel, should I keep using the Xen virtual server with Centos or should I switch to KVM? I am running Centos 5.7 now. I guess the real question is can I still use Xen with Centos 6? The support end of life for CentOS 5 is listed as March 31, 2014 ( http://wiki.centos.org/FAQ/General#head-fe8a0be91ee3e7dea812e8694491e1dde5b75e6d). There isn't any pressure, at this point, to convert your VM hosts to CentOS 6 unless there is some feature you require. I doubt RH will add XEN support to RHEL 6. They don't like to add functionality to an existing product. We can hope they bring XEN back in RHEL 7. While Xen will probably return in RHEL 7 simply because it is part of the upstream kernel now I doubt it will be officially supported by Red Hat. Between buying Qumranet (http://www.redhat.com/promo/qumranet/) and now Gluster (https://www.redhat.com/promo/storage/) it is clear that Red Hat aims to become a provider of a complete independent virtualization stack and is unlikely to support competing products directly. The question is what does Xen offer that KVM cannot provide? Looking at the slides of the KVM Forum 2011 (http://www.linux-kvm.org/page/KVM_Forum_2011 ) there seem to be many interesting improvements in the pipeline so at some point the question really is why hold on to Xen at all when there is not real reason to? The majority of hardware in my office server room, and both my home servers, are not HVM-capable, so they are not able to run KVM. Of course, as time goes on, this use case would eventually go away as well. However, I'll probably end up staying with Xen as long as possible, if for no other reason than I just like it better. jerry ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
[CentOS] Kerberos auth
Hello, I'm thinking of implementing centralized authentication using Kerberos on 48 servers, all Linux. I have no Active Directory. Can you please point me out to where I should RTFM :-) maybe some of you have tips or tutorials for me. Cheers! ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Odd issue with C6 and NIS
- Original Message - | On Wed, 5 Oct 2011, Steve Rikli wrote: | | Why? I'll grant NIS is insecure at best for login auth, and should | not | be used for that purpose (at least not outside the lab). | | But for other purposes e.g. automount maps, NIS is simple and easy | and | still functional. | | I'll also readily agree I wouldn't want NIS on internet-facing | systems, | but for things like automount maps on the internal corporate LAN, is | it really a catastropic problem? | | The problem you get is when you compare it with LDAP. | | jh There is no comparison. NIS is *much* faster than LDAP for these purposes. -- James A. Peltier IT Services - Research Computing Group Simon Fraser University - Burnaby Campus Phone : 778-782-6573 Fax : 778-782-3045 E-Mail : jpelt...@sfu.ca Website : http://www.sfu.ca/itservices http://blogs.sfu.ca/people/jpeltier I will do the best I can with the talent I have ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Kerberos auth
Am 06.10.2011 10:38, schrieb Bazy: Hello, I'm thinking of implementing centralized authentication using Kerberos on 48 servers, all Linux. I have no Active Directory. Can you please point me out to where I should RTFM :-) maybe some of you have tips or tutorials for me. Cheers! ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos Hello, the official Redhat handbooks are usefull: http://www.centos.org/docs/5/html/Deployment_Guide-en-US/ch-kerberos.html Greetings ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Odd issue with C6 and NIS
On Thu, 6 Oct 2011, James A. Peltier wrote: | The problem you get is when you compare it with LDAP. | | jh There is no comparison. NIS is *much* faster than LDAP for these purposes. And slow (and let's put it into context here, not *that* slow) performance of automount map resolution bites your setup how? jh ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Migrating CentOS 5 - 6: where to put /etc/inittab respawn scripts?
On Wednesday 05 Oct 2011 18:04:08 Alexander Farber wrote: My script has 2 pecularities: 1) When it gets SIGTERM or SIGINT, it writes some data into PostgreSQL and this takes 10-15 seconds 2) When it is started numerous times, then the subsequent runs will fail immediately, because only the 1st instance will be able to listen at the TCP-port 8080 And in /var/log/messages I see: ... 17:44:25 static init: pref main process ended, respawning 17:44:26 static init: pref main process (2128) terminated with status 98 17:44:26 static init: pref main process ended, respawning 17:44:26 static init: pref main process (2133) terminated with status 98 17:44:26 static init: pref respawning too fast, stopped is that all maybe the reason and is there something I could do? (maybe somehow delay the subsequent spawns?) To solve this problem you can add 'kill timeout 30' to pref.conf, this basically tells upstart that a process may take up to 30 seconds to exit after SIGTERM, and only if it doesn't exit after that it will send SIGKILL. But as for the issue of why upstart is not picking up the PID correctly, I'm not sure yet. I'm actually dealing with similar issue now so I'll post more when I find something. BTW, just noticed you're using su -c to run the program. I think this spawns a shell which may be the cause. Could you add 'expect fork' to pref.conf and see if it changes anything? -- Michael Gliwinski Henderson Group Information Services 9-11 Hightown Avenue, Newtownabby, BT36 4RT Phone: 028 9034 3319 ** The information in this email is confidential and may be legally privileged. It is intended solely for the addressee and access to the email by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients, any opinions or advice contained in this e-mail are subject to the terms and conditions expressed in the governing client engagement leter or contract. If you have received this email in error please notify supp...@henderson-group.com John Henderson (Holdings) Ltd Registered office: 9 Hightown Avenue, Mallusk, County Antrim, Northern Ireland, BT36 4RT. Registered in Northern Ireland Registration Number NI010588 Vat No.: 814 6399 12 * ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Kerberos auth
Take a look at FreeIPA, aka RHEL IPA which uses kerberos. Much easier to deploy kerberos using it and client config I done via a client rpm. David On Oct 6, 2011, at 3:38 AM, Bazy baz...@gmail.com wrote: Hello, I'm thinking of implementing centralized authentication using Kerberos on 48 servers, all Linux. I have no Active Directory. Can you please point me out to where I should RTFM :-) maybe some of you have tips or tutorials for me. Cheers! ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Kerberos auth
On Oct 6, 2011, at 3:38 AM, Bazy baz...@gmail.com wrote: I'm thinking of implementing centralized authentication using Kerberos on 48 servers, all Linux. I have no Active Directory. Can you please point me out to where I should RTFM :-) maybe some of you have tips or tutorials for me. Sorry, missed your email from 03:38, so I've also missed earlier responses. However, other than Kerberos, you might also consider openLDAP. Hopefully, the tools have *slightly* matured since '06 mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Kerberos auth
On Thu, Oct 06, 2011 at 11:38:11AM +0300, Bazy wrote: Hello, I'm thinking of implementing centralized authentication using Kerberos on 48 servers, all Linux. I have no Active Directory. Can you please point me out to where I should RTFM :-) maybe some of you have tips or tutorials for me. http://www.kerberos.org/software/adminkerberos.pdf From which I did some testing; write up at http://sweh.spuddy.org/Essays/Kerberos/ -- rgds Stephen ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Mock - Problems building Centos5 package on Centos6 - where can I ask for advice ?
Hi. I am trying to use Mock to rebuild a .src.rpm file I have made for PHP 5.3.8 (for Centos6) I have managed to install deps fine with mock. When I try to rebuild the package though I get. (from build.log) - + cat /usr/share/aclocal/libtool.m4 /usr/share/aclocal/ltoptions.m4 /usr/share/aclocal/ltsugar.m4 /usr/share/aclocal/ltversion.m4 /usr/share/aclocal/lt~obsolete.m4 cat: /usr/share/aclocal/ltoptions.m4: No such file or directory cat: /usr/share/aclocal/ltsugar.m4: No such file or directory cat: /usr/share/aclocal/ltversion.m4: No such file or directory cat: /usr/share/aclocal/lt~obsolete.m4: No such file or directory RPM build errors: error: Bad exit status from /var/tmp/rpm-tmp.90639 (%build) Bad exit status from /var/tmp/rpm-tmp.90639 (%build) Child returncode was: 1 EXCEPTION: Command failed. See logs for output. # ['bash', '--login', '-c', 'rpmbuild -bb --target x86_64 --nodeps builddir/build/SPECS/php.spec'] Traceback (most recent call last): File /usr/lib/python2.6/site-packages/mock/trace_decorator.py, line 70, in trace result = func(*args, **kw) File /usr/lib/python2.6/site-packages/mock/util.py, line 328, in do raise mock.exception.Error, (Command failed. See logs for output.\n # %s % (command,), child.returncode) Error: Command failed. See logs for output. # ['bash', '--login', '-c', 'rpmbuild -bb --target x86_64 --nodeps builddir/build/SPECS/php.spec'] LEAVE do -- EXCEPTION RAISED - (I can post the full build.log if needed) If this is not the correct place to ask about this can someone point me where I can ask ? Many regards ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Mock - Problems building Centos5 package on Centos6 - where can I ask for advice ?
On Thu, 6 Oct 2011, Morgan Cox wrote: Hi. I am trying to use Mock to rebuild a .src.rpm file I have made for PHP 5.3.8 (for Centos6) I have managed to install deps fine with mock. When I try to rebuild the package though I get. BuildRequires are wrong, since this SRPM requires files that aren't being pulled in. Add BuildRequires to satisfy these missing requirements and it'll work. jh ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Mock - Problems building Centos5 package on Centos6 - where can I ask for advice ?
There is my build of php-5.3.8 for el6: http://yum.aclub.net/pub/linux/centos/6/umask/SRPMS/php-5.3.8-4.el6.src.rpm You can find here BuildRequirements. Differences with upstream php: - subpackage for mod_php - subpackage with php-fpm init-scripts - suhosin patch / module - some other modules (rrdtools...) builds with php On Thu, Oct 6, 2011 at 6:53 PM, Morgan Cox morganco...@gmail.com wrote: Hi. I am trying to use Mock to rebuild a .src.rpm file I have made for PHP 5.3.8 (for Centos6) I have managed to install deps fine with mock. When I try to rebuild the package though I get. (from build.log) - + cat /usr/share/aclocal/libtool.m4 /usr/share/aclocal/ltoptions.m4 /usr/share/aclocal/ltsugar.m4 /usr/share/aclocal/ltversion.m4 /usr/share/aclocal/lt~obsolete.m4 cat: /usr/share/aclocal/ltoptions.m4: No such file or directory cat: /usr/share/aclocal/ltsugar.m4: No such file or directory cat: /usr/share/aclocal/ltversion.m4: No such file or directory cat: /usr/share/aclocal/lt~obsolete.m4: No such file or directory RPM build errors: error: Bad exit status from /var/tmp/rpm-tmp.90639 (%build) Bad exit status from /var/tmp/rpm-tmp.90639 (%build) Child returncode was: 1 EXCEPTION: Command failed. See logs for output. # ['bash', '--login', '-c', 'rpmbuild -bb --target x86_64 --nodeps builddir/build/SPECS/php.spec'] Traceback (most recent call last): File /usr/lib/python2.6/site-packages/mock/trace_decorator.py, line 70, in trace result = func(*args, **kw) File /usr/lib/python2.6/site-packages/mock/util.py, line 328, in do raise mock.exception.Error, (Command failed. See logs for output.\n # %s % (command,), child.returncode) Error: Command failed. See logs for output. # ['bash', '--login', '-c', 'rpmbuild -bb --target x86_64 --nodeps builddir/build/SPECS/php.spec'] LEAVE do -- EXCEPTION RAISED - (I can post the full build.log if needed) If this is not the correct place to ask about this can someone point me where I can ask ? Many regards ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos -- Ilyas R. Khasyanov Unix/Linux System Administrator GPG Key ID: 6EC5EB27 (Changed since 2009-05-12) ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Mock - Problems building Centos5 package on Centos6 - where can I ask for advice ?
Hi
Thank you for your extremely quick (and faster than support from any
company..) reply.
Sorry, can you give more detail ?
From the look of the error the 'mock centos5' is missing these files :-
/usr/share/aclocal/ltoptions.m4
/usr/share/aclocal/ltsugar.m4
/usr/share/aclocal/ltversion.m4
/usr/share/aclocal/lt~obsolete.m4
- which come from libtool2 (on centos6)
Centos5 obviously doesn't have that version...
I noticed in the .spec file it has
---
%build
# aclocal workaround - to be improved
cat `aclocal
--print-ac-dir`/{libtool,ltoptions,ltsugar,ltversion,lt~obsolete}.m4
aclocal.m4
# Force use of system libtool:
libtoolize --force --copy
cat `aclocal
--print-ac-dir`/{libtool,ltoptions,ltsugar,ltversion,lt~obsolete}.m4
build/libtool.m4
---
Ilyas , it isn't the fact that I can't build Centos6 PHP 5.3.8 - that works
fin in Centos6 - my issue is using the built src.rpm in mock so that it
builds for Centos5.
Thank you to everybody who responded.
Regards
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
[CentOS] CentOS 6 and Pyzor
Had anybody been successful in getting Pyzor to run on CentOS 6 64bit? I have it running fine on CentOS 6 32 bit, and I 'think' I did identical installs. But, from the command line I keep getting Oct 6 13:36:00.659 [16065] dbg: pyzor: network tests on, attempting Pyzor Oct 6 13:36:06.205 [16065] dbg: pyzor: pyzor is available: /usr/bin/pyzor Oct 6 13:36:06.206 [16065] dbg: pyzor: opening pipe: /usr/bin/pyzor check /tmp/.spamassassin160655GZkVEtmp Oct 6 13:36:06.281 [16065] dbg: pyzor: [16168] finished: exit 1 Oct 6 13:36:06.282 [16065] dbg: pyzor: check failed: no response And, yes the firewall port is open and I can ping pyzor. Been Googling this for hours now lots of returns without any helpful info. And 'odd' that it is running fine on 32 bit. And of course, the 32 bit install is for internal use while the 64 bit system needs to go live to the public really fast! -- John Hinton 877-777-1407 ext 502 http://www.ew3d.com Comprehensive Online Solutions ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Odd issue with C6 and NIS
In article alpine.lrh.2.00.1110060937180.9...@pfcpm187.yrrqf.np.hx, John Hodrien centos@centos.org wrote: On Wed, 5 Oct 2011, Steve Rikli wrote: ... I'll also readily agree I wouldn't want NIS on internet-facing systems, but for things like automount maps on the internal corporate LAN, is it really a catastropic problem? The problem you get is when you compare it with LDAP. Compare in what way? What characteristics are you contrasting? I'm genuinely trying to understand the problem you're talking about for the case I've presented, and pro-con from someone who has done both would be appreciated. Thanks, sr. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Odd issue with C6 and NIS
On Thu, 6 Oct 2011, Steve Rikli wrote: In article alpine.lrh.2.00.1110060937180.9...@pfcpm187.yrrqf.np.hx, John Hodrien centos@centos.org wrote: On Wed, 5 Oct 2011, Steve Rikli wrote: ... I'll also readily agree I wouldn't want NIS on internet-facing systems, but for things like automount maps on the internal corporate LAN, is it really a catastropic problem? The problem you get is when you compare it with LDAP. Compare in what way? What characteristics are you contrasting? I'm genuinely trying to understand the problem you're talking about for the case I've presented, and pro-con from someone who has done both would be appreciated. I'm not saying NIS is catastrophically bad for an internal system that you consider to be 'safe', it just comes from a time when security wasn't high up the list of worries. Other than it being easy as cake to setup in the first place, I think it's hard to list *any* honest advantages over LDAP. Sorry, I don't consider performance to be a credible advantage, especially after nscd/sssd have had their way with caching results. A good LDAP setup with nested groups, and GSSAPI just beats NIS over the head with a stick in terms of security, and once you've got a good LDAP infrastructure you start to discover just how many tools offer some form of LDAP integration. Extending the schema to suit internal uses is also easy, and querying it from within your own apps/scripts is far from difficult. jh ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Odd issue with C6 and NIS
In article alpine.lrh.2.02.1110062107400.21...@pfyva-tcf.pfhavk.pbzc.yrrqf.np.hx, John Hodrien centos@centos.org wrote: ... A good LDAP setup with nested groups, and GSSAPI just beats NIS over the head with a stick in terms of security, and once you've got a good LDAP infrastructure you start to discover just how many tools offer some form of LDAP integration. Extending the schema to suit internal uses is also easy, and querying it from within your own apps/scripts is far from difficult. Thanks, good perspective. [ about to display ignorance of LDAP ... ] So, back to my original example of automount maps (which I've long thought about implementing in LDAP but never pursued), how do you deal with the situation of needing map(s) loaded, without an active user on the system to authenticate the LDAP query with their username/password? That is, NIS clients bind to the NIS server, and thereby have access to auto.home map or what have you, whether a user ever logs into the client system or not. Automounter is functional and has the map data. What's the functional equivalent for LDAP automount maps? Cheers, sr. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Odd issue with C6 and NIS
On Thu, Oct 06, 2011 at 09:14:35PM +0100, John Hodrien wrote: place, I think it's hard to list *any* honest advantages over LDAP. Sorry, I don't consider performance to be a credible advantage, especially after nscd/sssd have had their way with caching results. Then you've never seen Veritas Cluster Services fall over 'cos of the amount of time it takes to do initgroup() stuff (VCS loves to su to oracle to verify the DB is up; the su takes too long 'cos this is a complete scan of the group map and nscd don't help, here; DB failover occurs). You've never seen unexpected DoS attacks 'cos of netstat -a 'cos of all the temporary ports 'cos nscd doesn't cache serv-by-port values when each request is a new port number. You've never seen... Oh, never mind. LDAP (being TCP connection oriented) is a world of hurt when it comes to stability and performance in any large environment. NIS, being UDP, allows you to just run. (By large, I'm talking 30,000 client machines on 5 continents). That said: A good LDAP setup with nested groups, and GSSAPI just beats NIS over the head with a stick in terms of security, and once you've got a good LDAP This is true. NIS security is awful. Which is why we use LDAP :-) -- rgds Stephen ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 6 and Pyzor
On 10/6/2011 1:37 PM, John Hinton wrote: Had anybody been successful in getting Pyzor to run on CentOS 6 64bit? I have it running fine on CentOS 6 32 bit, and I 'think' I did identical installs. But, from the command line I keep getting Oct 6 13:36:00.659 [16065] dbg: pyzor: network tests on, attempting Pyzor Oct 6 13:36:06.205 [16065] dbg: pyzor: pyzor is available: /usr/bin/pyzor Oct 6 13:36:06.206 [16065] dbg: pyzor: opening pipe: /usr/bin/pyzor check /tmp/.spamassassin160655GZkVEtmp Oct 6 13:36:06.281 [16065] dbg: pyzor: [16168] finished: exit 1 Oct 6 13:36:06.282 [16065] dbg: pyzor: check failed: no response And, yes the firewall port is open and I can ping pyzor. Been Googling this for hours now lots of returns without any helpful info. And 'odd' that it is running fine on 32 bit. And of course, the 32 bit install is for internal use while the 64 bit system needs to go live to the public really fast! OK, so I'm an idiot!!! arrgh! I started comparing every file and every directory for all of the anti-spam stuff and guess what I found? On the 64bit system sample-spam.txt had 0 bytes. Well, I suppose everything was working just as it should have been. That file on the 32 bit system has a date of March 16 2010, so I didn't put that text in there. Anyway, after adding in the spam text on the 64 bit system... it all works. Why is it so often that the most obvious is the hardest to find? And why is this a 0 byte file instead of just not being there at all? On the 32bit system, spamassassin was installed from base. On the 64bit system, spamassassin was installed from anaconda during full server installation. -- John Hinton 877-777-1407 ext 502 http://www.ew3d.com Comprehensive Online Solutions ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Odd issue with C6 and NIS
On Thu, 6 Oct 2011, Stephen Harris wrote: On Thu, Oct 06, 2011 at 09:14:35PM +0100, John Hodrien wrote: place, I think it's hard to list *any* honest advantages over LDAP. Sorry, I don't consider performance to be a credible advantage, especially after nscd/sssd have had their way with caching results. Then you've never seen Veritas Cluster Services fall over 'cos of the amount of time it takes to do initgroup() stuff (VCS loves to su to oracle to verify the DB is up; the su takes too long 'cos this is a complete scan of the group map and nscd don't help, here; DB failover occurs). As I said with my nscd/sssd comment, you need a client that's not total crap. nss_ldap isn't up to dealing with large ldap setup, especially with nested groups. sssd 1.6.1, suitably configured *is* up to it. I've tested it with give or take 100k users and 100k groups. nscd with nss_ldap isn't up to it, as the caching is done at the wrong time, and it doesn't understand anything about LDAP. I've seen ssh time out with a nss_ldap setup due to a slow initgroups. Your only option there is: nss_getgrent_skipmembers true That gets your performance up to a pretty tasty level, but it *will* break some things. sssd correctly configured gets you to only a small distance behind that setup, but without the breakage, and it handles failures of LDAP servers *much* better. You've never seen unexpected DoS attacks 'cos of netstat -a 'cos of all the temporary ports 'cos nscd doesn't cache serv-by-port values when each request is a new port number. nscd is a pile of pants, I fully accept. You've never seen... Oh, never mind. LDAP (being TCP connection oriented) is a world of hurt when it comes to stability and performance in any large environment. NIS, being UDP, allows you to just run. (By large, I'm talking 30,000 client machines on 5 continents). So with sssd you're looking at persistent connections, sensible failover between servers, and caching that understands the reality of ldap, not just the NSS level. It really is a different world to be playing in. I'd been longing for a better solution, but wasn't totally sold on the nss_ldapd stuff that was lurking. sssd, and the winning attitude of the developers to addressing problems has been a revolution to me. Caching that happens *before* your cache expires... Seriously, sssd ticks so many boxes. If you've not had a look at sssd, *do*, and by all means drop me a line or on the sssd mailing list if you have problems. It's *not* perfect, but from my perspective it's so far towards right I can forgive all the problems. This is true. NIS security is awful. Which is why we use LDAP :-) ;) jh ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Odd issue with C6 and NIS
On Thu, 6 Oct 2011, Steve Rikli wrote: So, back to my original example of automount maps (which I've long thought about implementing in LDAP but never pursued), how do you deal with the situation of needing map(s) loaded, without an active user on the system to authenticate the LDAP query with their username/password? That is, NIS clients bind to the NIS server, and thereby have access to auto.home map or what have you, whether a user ever logs into the client system or not. Automounter is functional and has the map data. You need an account that can do lookups. Either you have one 'lookup' account that you share between multiple machines, or you do it AD style and have an account per machine. As I do it, this auth is done with a kerberos keytab credential with GSSAPI. What's the functional equivalent for LDAP automount maps? Automount maps work just nicely in LDAP, there's a standard schema and you just populate the records and it works. jh ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Odd issue with C6 and NIS
On Thu, Oct 06, 2011 at 10:28:58PM +0100, John Hodrien wrote: On Thu, 6 Oct 2011, Stephen Harris wrote: Then you've never seen Veritas Cluster Services fall over 'cos of the amount of time it takes to do initgroup() stuff (VCS loves to su to oracle to verify the DB is up; the su takes too long 'cos this is a complete scan of the group map and nscd don't help, here; DB failover occurs). As I said with my nscd/sssd comment, you need a client that's not total crap. Which, up until a few months ago, was no client. Solaris is crap (they recently rewrote their caching infrastructure to make it better); AIX is crap (with it's own unique solution and persistent connections). HPUX is crap Oh wait... what this really means is that _LDAP_ is crap at performance and each and every client needs to have massive kludges and work-arounds (that aren't necessary with NIS) in order to resume some semblence of usability. And once you move out of normal naming services and into custom maps then your LDAP world of pain gets even worse; I'll always be able to do a ypmatch quicker than an ldapsearch. about LDAP. I've seen ssh time out with a nss_ldap setup due to a slow initgroups. Your only option there is: nss_getgrent_skipmembers true You might as well not use secondary groups at all, then! Dammit; why didn't UDP based LDAP ever take off? That would have helped, a lot! -- rgds Stephen ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Odd issue with C6 and NIS
On Thu, 6 Oct 2011, Stephen Harris wrote: Which, up until a few months ago, was no client. Solaris is crap (they recently rewrote their caching infrastructure to make it better); AIX is crap (with it's own unique solution and persistent connections). HPUX is crap ;) Oh wait... what this really means is that _LDAP_ is crap at performance and each and every client needs to have massive kludges and work-arounds (that aren't necessary with NIS) in order to resume some semblence of usability. Only I don't buy into that. Too much of NSS assumes that linear searching through the user information is the quickest route, and that's just plain dumb in complicated setups with more advanced sources of information (like LDAP). And once you move out of normal naming services and into custom maps then your LDAP world of pain gets even worse; I'll always be able to do a ypmatch quicker than an ldapsearch. Why? GSSAPI means I don't have to provide any authentication information, and ldapsearch isn't that annoying. ypmatch is far cruder than ldapsearch, so while a simple search with ypmatch might be quicker, compound queries end up being much easier with ldapsearch. List me all of the users who work in a given department who have access to a given resource and tell me their display name and phone number. ldapsearch makes that simple. If you want to go a step further (and personally I don't) store their ssh public keys in LDAP. nss_getgrent_skipmembers true You might as well not use secondary groups at all, then! I *did* say that nss_ldap is broken! I was actually quietly surprised at how few things look to see who is a member of a group rather than query which groups a user is a member of. Even with this set, 95% of things works perfectly with secondary groups. Unfortunately chgrp and newgrp don't work without patching, which is a pain. But most things do an initgroup and don't worry about the group actually containing no members. Dammit; why didn't UDP based LDAP ever take off? That would have helped, a lot! Is the connection side that big a deal when you've got a daemon managing persistent connections to the servers? jh ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Odd issue with C6 and NIS
In article alpine.lrh.2.02.1110062229170.24...@pfyva-tcf.pfhavk.pbzc.yrrqf.np.hx, John Hodrien centos@centos.org wrote: On Thu, 6 Oct 2011, Steve Rikli wrote: So, back to my original example of automount maps (which I've long thought about implementing in LDAP but never pursued), how do you deal with the situation of needing map(s) loaded, without an active user on the system to authenticate the LDAP query with their username/password? That is, NIS clients bind to the NIS server, and thereby have access to auto.home map or what have you, whether a user ever logs into the client system or not. Automounter is functional and has the map data. You need an account that can do lookups. Either you have one 'lookup' account that you share between multiple machines, That's what I thought. But doesn't that lookup account need to have a published password (and likewise, hardcoded in scripts and config files and whatnot) in order to do the LDAP querying without end-user interactivity? Granted, we're talking about public data in this example (i.e. automount map data) so security isn't a concern for that part; but the lookup account could potentially be used for other means, yes? or you do it AD style and have an account per machine. OK for user workstations, impractical when you're talking about servers, no? Or do I misunderstand your example? As I do it, this auth is done with a kerberos keytab credential with GSSAPI. Sounds like I would need to research that, then. This replaces the need for the lookup account, or augments it, or something else entirely? What's the functional equivalent for LDAP automount maps? Automount maps work just nicely in LDAP, there's a standard schema and you just populate the records and it works. I grok'd that part; it was the NIS binding sort of equivalent behavior that I was specifically interested in for LDAP. Cheers, sr. -- || Steve Rikli ||| Every normal man must be tempted, at|| || Systems Administrator ||| times, to spit on his hands, hoist the || || Genyosha Networks ||| black flag, and begin slitting throats. || || s...@genyosha.net ||| - H. L. Mencken || ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Odd issue with C6 and NIS
On Thu, Oct 06, 2011 at 11:17:42PM +0100, John Hodrien wrote: On Thu, 6 Oct 2011, Stephen Harris wrote: And once you move out of normal naming services and into custom maps then your LDAP world of pain gets even worse; I'll always be able to do a ypmatch quicker than an ldapsearch. Why? GSSAPI means I don't have to provide any authentication information, and ldapsearch isn't that annoying. ypmatch is far cruder than ldapsearch, so ldapsearch requires a new TCP connection; slow. while a simple search with ypmatch might be quicker, compound queries end up being much easier with ldapsearch. List me all of the users who work in a Compound queries belong in a database. given department who have access to a given resource and tell me their display name and phone number. ldapsearch makes that simple. If you want to go a I wouldn't do that in NIS. Why would my OS care about it?. But I would do tell me the path to the latest version of application X 100s of times per minute. ldapsearch adds massive overhead (2 orders of magnitude) to the return. The right tools for the job; fast lightweight efficient protocols for the OS where we get millions of calls; slower heavier weight calls for applications that make calls once a minute or slower. I *did* say that nss_ldap is broken! I was actually quietly surprised at how few things look to see who is a member of a group rather than query which groups a user is a member of. Even with this set, 95% of things works getgrnam(foo) to see who is in a group is nice and efficient for a connection that's already open. initgroups (which _has_ to do a while(getrgrent()) loop) is slow. Logins and su and similar do initgroups. Dammit; why didn't UDP based LDAP ever take off? That would have helped, a lot! Is the connection side that big a deal when you've got a daemon managing persistent connections to the servers? ldapsearch doesn't use the connection manager. Unless you're now replacing tonnes of tools (and the perl Net::LDAP module and the python module and the apache LDAP module and...) -- rgds Stephen ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Odd issue with C6 and NIS
On Thu, 6 Oct 2011, Steve Rikli wrote: That's what I thought. But doesn't that lookup account need to have a published password (and likewise, hardcoded in scripts and config files and whatnot) in order to do the LDAP querying without end-user interactivity? Yes. Either you're talking about a samba tdb file, a password in plain text, or a kerberos keytab file. GSSAPI means you don't need to hardcode anything, as it just fishes around in your keytab. Granted, we're talking about public data in this example (i.e. automount map data) so security isn't a concern for that part; but the lookup account could potentially be used for other means, yes? It can be used to do what you grant it access to do (but it can be constrained). That's not worse than NIS. or you do it AD style and have an account per machine. OK for user workstations, impractical when you're talking about servers, no? Or do I misunderstand your example? Account per machine is fine. As part of your install do a 'net ads join' (in AD speak), and you're done. You'll want kerberos credentials per machine anyway, so it's nothing new. Servers more than clients want kerberos credentials, as lots of services can benefit from kerberos authentication (httpd, cups, nfs, ssh, smtp, imap...). As I do it, this auth is done with a kerberos keytab credential with GSSAPI. Sounds like I would need to research that, then. This replaces the need for the lookup account, or augments it, or something else entirely? If you're generating a keytab per machine (which you want for kerberised services), then having a credential within that that's able to do lookups isn't a big extra. Look at FreeIPA as suggested, as this wraps all this up and makes it quite straightforward (in much of the same way as MS AD does). jh ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Odd issue with C6 and NIS
On Thu, 6 Oct 2011, Stephen Harris wrote: On Thu, Oct 06, 2011 at 11:17:42PM +0100, John Hodrien wrote: On Thu, 6 Oct 2011, Stephen Harris wrote: And once you move out of normal naming services and into custom maps then your LDAP world of pain gets even worse; I'll always be able to do a ypmatch quicker than an ldapsearch. Why? GSSAPI means I don't have to provide any authentication information, and ldapsearch isn't that annoying. ypmatch is far cruder than ldapsearch, so ldapsearch requires a new TCP connection; slow. Right, so how often do you want to do a single query where performance is that critical? SSSD maintains connections, so it's not one connection per query. And slow is a very vague term: time ldapsearch 'cn=someuser' /dev/null real0m0.017s So with all the GSSAPI authentication and the TCP connection and finding the right entry it takes how long? I know you were talking about more WAN type connections, but persistent connections with SSSD should deal with that performance hit shouldn't it? while a simple search with ypmatch might be quicker, compound queries end up being much easier with ldapsearch. List me all of the users who work in a Compound queries belong in a database. Probably you're right, but as a user of LDAP is sometimes find need to do them, and I'm not going to store the information twice. I wouldn't do that in NIS. Why would my OS care about it?. But I would do tell me the path to the latest version of application X 100s of times per minute. Which should all be cached at the client side. ldapsearch adds massive overhead (2 orders of magnitude) to the return. The right tools for the job; fast lightweight efficient protocols for the OS where we get millions of calls; slower heavier weight calls for applications that make calls once a minute or slower. If there are millions of calls you can't afford to be asking the network, especially on things like this where odds are you're only talking about the value changing relatively rarely. I *did* say that nss_ldap is broken! I was actually quietly surprised at how few things look to see who is a member of a group rather than query which groups a user is a member of. Even with this set, 95% of things works getgrnam(foo) to see who is in a group is nice and efficient for a connection that's already open. initgroups (which _has_ to do a while(getrgrent()) loop) is slow. Logins and su and similar do initgroups. Yes, but relatively few things do the former. You specify AllowGroups blah in sshd_config, and ssh doesn't check who is a member of that group, it does an initgroups instead. Dammit; why didn't UDP based LDAP ever take off? That would have helped, a lot! Is the connection side that big a deal when you've got a daemon managing persistent connections to the servers? ldapsearch doesn't use the connection manager. Unless you're now replacing tonnes of tools (and the perl Net::LDAP module and the python module and the apache LDAP module and...) No, but for a lot of these things querying through nss is an option. jh ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Odd issue with C6 and NIS
On Thu, Oct 06, 2011 at 11:47:21PM +0100, John Hodrien wrote: On Thu, 6 Oct 2011, Stephen Harris wrote: I wouldn't do that in NIS. Why would my OS care about it?. But I would do tell me the path to the latest version of application X 100s of times per minute. Which should all be cached at the client side. You're missing the point. If the query was sufficiently fast then you don't _need_ to worry about caching, and thus cache coherency, speed of propagation of changes, inconsistent results between machines etc etc. Caching is a _kludge_ to hide an underlying problem. It adds complexity and additional failure modes. LDAP is slow. nscd, sssd, ldapcachemgr et al are all klduges to work around that fact. And the whole world isn't nss. The reality is that we're screwed; LDAP became the God Of Naming Services and everybody rushed into it (didn't help that Sun's NIS+ was just plain bloody awful). And so we're paying the price; caching has become essential. We (where I work) moved into LDAP a decade ago. And it's only now that the OS performance is beginning to approach that of a NIS client. -- rgds Stephen ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Odd issue with C6 and NIS
In article alpine.lrh.2.02.1110062331450.27...@pfyva-tcf.pfhavk.pbzc.yrrqf.np.hx, John Hodrien centos@centos.org wrote: On Thu, 6 Oct 2011, Steve Rikli wrote: That's what I thought. But doesn't that lookup account need to have a published password (and likewise, hardcoded in scripts and config files and whatnot) in order to do the LDAP querying without end-user interactivity? Yes. Either you're talking about a samba tdb file, a password in plain text, or a kerberos keytab file. GSSAPI means you don't need to hardcode anything, as it just fishes around in your keytab. Granted, we're talking about public data in this example (i.e. automount map data) so security isn't a concern for that part; but the lookup account could potentially be used for other means, yes? It can be used to do what you grant it access to do (but it can be constrained). That's not worse than NIS. Well, somewhat. E.g. my NIS master doesn't need to publish a passwd map in order to provide auto.home map or whatever, and I don't need a lookup account to get at the required data in the case of NIS. [ other useful info ideas for research deleted for brevity ] Thanks for the discussion sharing the benefits of your experience, John -- much appreciated. Cheers, sr. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Kerberos auth
On Thursday, October 06, 2011 08:52 PM, m.r...@5-cent.us wrote: On Oct 6, 2011, at 3:38 AM, Bazybaz...@gmail.com wrote: I'm thinking of implementing centralized authentication using Kerberos on 48 servers, all Linux. I have no Active Directory. Can you please point me out to where I should RTFM :-) maybe some of you have tips or tutorials for me. Sorry, missed your email from 03:38, so I've also missed earlier responses. However, other than Kerberos, you might also consider openLDAP. Hopefully, the tools have *slightly* matured since '06 What about opendj? ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Odd issue with C6 and NIS
On Thu, 2011-10-06 at 19:10 -0400, Stephen Harris wrote: On Thu, Oct 06, 2011 at 11:47:21PM +0100, John Hodrien wrote: On Thu, 6 Oct 2011, Stephen Harris wrote: I wouldn't do that in NIS. Why would my OS care about it?. But I would do tell me the path to the latest version of application X 100s of times per minute. Which should all be cached at the client side. You're missing the point. If the query was sufficiently fast then you don't _need_ to worry about caching, and thus cache coherency, speed of propagation of changes, inconsistent results between machines etc etc. Caching is a _kludge_ to hide an underlying problem. It adds complexity and additional failure modes. LDAP is slow. nscd, sssd, ldapcachemgr et al are all klduges to work around that fact. And the whole world isn't nss. The reality is that we're screwed; LDAP became the God Of Naming Services and everybody rushed into it (didn't help that Sun's NIS+ was just plain bloody awful). And so we're paying the price; caching has become essential. We (where I work) moved into LDAP a decade ago. And it's only now that the OS performance is beginning to approach that of a NIS client. OpenLDAP is highly optimized and very fast and can search a large DSA much quicker than you can search a large passwd/group setup. Maybe the LDAP setup at your workplace is really slow but it might be a mistake to characterize all LDAP services as slow. I find Fedora DS (aka 389, formerly the Netscape DS) to be considerably slower than OpenLDAP but not every puts the ultimate premium on LDAP speed. For the record... ldap does have a 'socket' mode that one can use on a local machine where speed is of the essence so that sort of blunts the point you are trying to make about TCP/IP speeds. I would agree with NSCD adding additional mode failures. I try not to use it. I know nothing at all about other cache technologies for LDAP. SSD really isn't about user/group caching and I'm not sure how that worked its way in here. http://fedoraproject.org/wiki/Features/SSSD In reality, you're going to have to use something like libnss or sssd for any alternative authentication system. What I see is that the hardware is sufficiently fast enough to tolerate latency via virtualization in favor of flexibility, mobility, disaster recovery, etc. and speed is clearly not the only thing and often not the most important thing. Personally, I think you are making a fallacious argument and offering no empirical evidence, no comparison testing methodology and no evidence of anything worthwhile to consider. Craig -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] guest vms crash host systems -- SOLVED
On Wed, Oct 5, 2011 at 10:27 PM, Negative negativebinom...@gmail.comwrote: On Wed, Oct 5, 2011 at 3:11 PM, Negative negativebinom...@gmail.comwrote: On Wed, Oct 5, 2011 at 3:06 PM, Negative negativebinom...@gmail.comwrote: On Wed, Oct 5, 2011 at 1:00 PM, m.r...@5-cent.us wrote: Negative wrote: On Wed, Oct 5, 2011 at 11:15 AM, m.r...@5-cent.us wrote: Negative wrote: On Wed, Oct 5, 2011 at 11:15 AM, m.r...@5-cent.us wrote: Negative wrote: snip I still wonder what is causing this. I couldn't find any mention of a similar problem, including on my desktop in my office, where I have a very similar setup, with four kvm guests, two Fedora, one Centos 6 and one Windows XP. snip Do I remember this is 5.7? Look at the announcement that *just* came out in the last hour, with the libX11 bugfix. https://rhn.redhat.com/errata/RHBA-2011-1351.html says Previously, in the 64-bit mode, libX11 computed addresses using the 32-bit arithmetic. As a consequence, under heavy load, applications running in the X environment terminated unexpectedly. A patch has been provided to address this issue, and the crashes no longer occur in the described scenario. mark And, Mark, thanks for mentioning it. If this isn't my lucky day. RH and Centos solved my problem even before I defined it. I saw the update earlier and didn't dare hope. I updated and it seems to have solved the issue. On the host machine, I fired up virt-manager, started the Fedora guest and it's been up for a half hour. Now I, too, can start complaining about Gnome 3. I've read it's like Windows, but it's the spitting image of the Mac OS. I spoke too soon. Crashed again after being up for several hours. I'm running memtest86 now. After memtest found no errors, I gave another shot at looking for a software reason for the crashes and found the cause. I hadn't mention that I messed up the bridge setup. I didn't think that could lock up the host machine, but it did. Once I had the bridge fixed, the crashing stopped and network has been working on the guest. So it was my bad there. I thought that an incorrect network config would only affect networking, but it was causing a kernel panic. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
