On 30 May 2014, at 3:01 am, Jay G. Scott <g...@arlut.utexas.edu> wrote:
> On Wed, May 28, 2014 at 07:42:58PM -0400, Digimer wrote: >> On 28/05/14 05:05 PM, Jay G. Scott wrote: >>> >>> Greetings, >>> >>> I'm a noob. If this isn't the right place to ask this, >>> let me know. I took "general configuration questions" >>> to include compiling. >>> >>> OS = RHEL6 (I hope) x86_64 >>> >>> I downloaded: >>> Reusable-Cluster-Components-glue--glue-1.0.9.tar.bz2 >>> Heartbeat-3-0-7e3a82377fa8.tar.bz2 >>> ClusterLabs-resource-agents-v3.9.2-0-ge261943.tar.gz >>> >>> Errr.... I just now noticed this. Is there a Pacemaker source tarball >>> somewhere? 'Cause I guess I don't have it. >>> >>> >>> I wrote a book on using autotools and making RPMs. >>> Looks like the existing packages could use some work. >>> Heartbeat can't find the libltdl.tar file to install >>> a local version, but I have a feeling the packages >>> I have installed already should make that a moot point. >>> >>> >>> Back to my problem: >>> >>> I compiled and installed >>> Reusable-Cluster-Components-glue--glue-1.0.9.tar.bz2 >>> >>> Then I pressed on to Heartbeat. According to what I read >>> online that's the proper order. >>> >>> 1. I have a libltdl.so.7 library but the configure script >>> claims it does not have lt_ldopen(). I decided to bluster >>> my way past that, in the hopes that the routine wouldn't >>> really be needed. >>> >>> 2. But now it can't find ltdl.h, and I can't readily find a >>> way around that. Ie, I can't find a RH package that >>> has that header file. libtool and libtool-ltdl are both >>> installed. >>> >>> [root@w1dns ~]# rpm -q -a | grep libtool >>> libtool-2.2.6-15.5.el6.x86_64 >>> libtool-ltdl-2.2.6-15.5.el6.x86_64 >>> >>> Are there pre-built versions of these things somewhere? >>> I'm not anxious to re-invent the wheel. >>> Are there more parts to this than I have? >>> >>> j. >> >> I think you might want to be sure you're using the right stack. >> >> Trick is, there are two answers for this. >> >> Under RHEL 6, the fully supported stack is corosync + cman + rgmanager. >> This has been Red Hat's stack since it got into the HA game, and will be >> supported until 2020 when RHEL 6 support ends. >> >> The other answer is corosync + pacemaker (+cman). This support is nearly >> complete, but not totally complete. It got out of "Tech Preview" at the >> end of the 6.4 stream and is effectively fully supported on 6.5 an >> onward. Further, this will be the only supported stack on RHEL 7 and >> forward. >> >> In either case, heartbeat is long deprecated (though still supported by >> Linbit, whom Red Hat has a support deal with). It has not been actively >> supported in years and there is no plan to restart development in the >> future. So please, do not use it. >> >> If you're curious about the reasons for all this, I have an >> incomplete-but-still-hopefully-helpful history of HA coming together >> here: >> >> https://alteeve.ca/w/History_of_HA_Clustering > > i made a note to go check this. > > >> >> So to best help you, can I ask what your near and long-term goals are? > > joke's on me: > > yeah, you can ask. and as of about 15 minutes ago they changed. > > near term -- now, nothing. > longer term -- looks like i'd need to move to Centos or one of the > other cost-free OSes. sigh. > > so, thanks -- sincerely -- for the RH answer. > what's the answer for ... Centos, I guess...? And it does > embarrass me to have to ask that. For paid "fix this right now!" support, then SLES and RHEL (6.5+) are good options (both pay people to work on pacemaker). There is also the option of talking to a cross-distro vendor like Linbit. CentOS is a good free option as you get something enterprise ready and can piggy back off the fixes that go into RHEL. The downside is that your problems need to be likely to affect paying customers before they can be prioritised and there can be a decent delay between a fix being available and shipped. In some ways though, you can be better off running your favourite distro plus the latest from upstream. Thats what the developers are using every day and all fixes are available immediately. The project's regression tests get performed on every commit and are expansive enough that pretty much anything that makes it into the public source tree is quite usable. The source trees for most things are at: http://github.com/ClusterLabs > > j. > > >> Once you've identified which stack is best for your use-case, we can >> better help you identify compilation issues (or if you need to be >> compiling anything at all). >> >> Cheers >> >> -- >> Digimer >> Papers and Projects: https://alteeve.ca/w/ >> What if the cure for cancer is trapped in the mind of a person without >> access to education? >> _______________________________________________ >> Linux-HA mailing list >> Linux-HA@lists.linux-ha.org >> http://lists.linux-ha.org/mailman/listinfo/linux-ha >> See also: http://linux-ha.org/ReportingProblems > > -- > Jay Scott 512-835-3553 g...@arlut.utexas.edu > Head of Sun Support, Sr. System Administrator > Applied Research Labs, Computer Science Div. S224 > University of Texas at Austin > _______________________________________________ > Linux-HA mailing list > Linux-HA@lists.linux-ha.org > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
