Re: [D*] CentOS installation issues - libcurl

[John Castronuovo]

wouldn't you try to get the libcurl-devel package?




On 3/22/13 9:32 PM, Robert R wrote:

Hey all,

Let me preface this by saying that I'm comfortable working in but not that well versed on the command line, especially in the RH flavor, as I've been more partial to Debian / Ubuntu in the past.

Anyway, I've been running into an issue installing a pod to run on a CentOS 5.9 server, relating to libcurl, libidn, and typhoeus. I believe that I've been successful getting all the required versions of the 'pre-req's installed. (I ran into some version issues, as it seems CentOS 5.9's repos weren't supplying me with up-to-date-enough packages, but I was able to get around these problems)

When I 'bundle install', it does it's thing for a while, steadily marching it's way through it's list, until it fails at typhoeus. Here's the output:

Installing typhoeus (0.3.3)
Gem::Installer::ExtensionBuildError: ERROR: Failed to build gem native extension.

        /home/user/.rvm/rubies/ruby-1.9.3-p385/bin/ruby extconf.rb
extconf.rb:9: Use RbConfig instead of obsolete and deprecated Config.
checking for curl/curl.h in /opt/local/include,/opt/local/include/curl,/home/user/.rvm/rubies/ruby-1.9.3-p385/include/curl,/home/user/.rvm/rubies/ruby-1.9.3-p385/include,/usr/include/curl,/usr/local/include/curl... no
need libcurl
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of
necessary libraries and/or headers.  Check the mkmf.log file for more
details.  You may need configuration options.

Provided configuration options:
    --with-opt-dir
    --with-opt-include
    --without-opt-include=${opt-dir}/include
    --with-opt-lib
    --without-opt-lib=${opt-dir}/lib
    --with-make-prog
    --without-make-prog
    --srcdir=.
    --curdir
    --ruby=/home/user/.rvm/rubies/ruby-1.9.3-p385/bin/ruby


Gem files will remain installed in /home/user/.rvm/gems/ruby-1.9.3-p385@diaspora/gems/typhoeus-0.3.3 for inspection.
Results logged to /home/user/.rvm/gems/ruby-1.9.3-p385@diaspora/gems/typhoeus-0.3.3/ext/typhoeus/gem_make.out

An error occurred while installing typhoeus (0.3.3), and Bundler cannot
continue.
Make sure that `gem install typhoeus -v '0.3.3'` succeeds before bundling.

So, what I get of it (and the output is identical for `gem install typhoeus -v '0.3.3'`) is: usr/local/include/curl... no need libcurl

Ok, so let's get libcurl:

$ sudo yum install libcurl
Loaded plugins: fastestmirror, security
Loading mirror speeds from cached hostfile
 * base: centos-mirror.jchost.net
 * epel: fedora-epel.mirror.lstn.net
 * extras: centos.mirror.lstn.net
 * updates: mirror.anl.gov
Setting up Install Process
No package libcurl available.
Nothing to do

Hmm, no package libcurl available. Alright, lets find it and install it manually:

$ sudo yum install libcurl-7.29.0-4.0.cf.rhel5.x86_64.rpm
Loaded plugins: fastestmirror, security
Loading mirror speeds from cached hostfile
 * base: centos-mirror.jchost.net
 * epel: fedora-epel.mirror.lstn.net
 * extras: centos.mirror.lstn.net
 * updates: mirror.anl.gov
Setting up Install Process
Examining libcurl-7.29.0-4.0.cf.rhel5.x86_64.rpm: libcurl-7.29.0-4.0.cf.rhel5.x86_64
Marking libcurl-7.29.0-4.0.cf.rhel5.x86_64.rpm to be installed
Resolving Dependencies
--> Running transaction check
---> Package libcurl.x86_64 0:7.29.0-4.0.cf.rhel5 set to be updated
--> Processing Dependency: libidn.so.11(LIBIDN_1.0)(64bit) for package: libcurl
--> Finished Dependency Resolution
libcurl-7.29.0-4.0.cf.rhel5.x86_64 from /libcurl-7.29.0-4.0.cf.rhel5.x86_64 has depsolving problems
  --> Missing Dependency: libidn.so.11(LIBIDN_1.0)(64bit) is needed by package libcurl-7.29.0-4.0.cf.rhel5.x86_64 (/libcurl-7.29.0-4.0.cf.rhel5.x86_64)
Error: Missing Dependency: libidn.so.11(LIBIDN_1.0)(64bit) is needed by package libcurl-7.29.0-4.0.cf.rhel5.x86_64 (/libcurl-7.29.0-4.0.cf.rhel5.x86_64)
 You could try using --skip-broken to work around the problem
 You could try running: package-cleanup --problems
                        package-cleanup --dupes
                        rpm -Va --nofiles --nodigest

And our next error, apparently it's missing libidn.so.11. So... where is it?

$ locate libidn.so.11
/home/user/libidn.so.11
/usr/lib/libidn.so.11
/usr/lib/libidn.so.11.5.19
/usr/lib64/libidn.so.11
/usr/lib64/libidn.so.11.5.19

Ok, apparently it's all over the place (including some places I 'cp'ed it to) but why won't it pick it up? I even downloaded the most up to date rpms I could find: libidn-1.26-2.rhel5.x86_64.rpm and libidn-devel-1.26-2.rhel5.x86_64.rpm, but trying to install them throws a recursive error referring back to libidn.so.11.

At this point I'm at a total loss, and very near the limits of my understanding and knowledge. Where do I go from here?
--
You received this message because you are subscribed to the Google Groups "diaspora-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diaspora-dev...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Florian Staudacher]

Hi Robert!

I'd recommend you use at least CentOS 6.

There have been issues with the libs you mentioned due to the conservative
(old) versions that are in the CentOS repos.

And, of course, you'll need the *-devel packages for compiling the bindings.

- Raven24

Am Freitag 22 März 2013, 18:32:22 schrieb Robert R:
> Hey all,
>
> Let me preface this by saying that I'm comfortable working in but not that
> well versed on the command line, especially in the RH flavor, as I've been
> more partial to Debian / Ubuntu in the past.
>
> Anyway, I've been running into an issue installing a pod to run on a CentOS
> 5.9 server, relating to libcurl, libidn, and typhoeus. I believe that I've
> been successful getting all the required versions of the 'pre-req's

> installed. *(I ran into some version issues, as it seems CentOS 5.9's repos

> weren't supplying me with up-to-date-enough packages, but I was able to get
> around these problems)
>

> *When I 'bundle install', it does it's thing for a while, steadily marching

> So, what I get of it (*and the output is identical for **`gem install
> typhoeus -v '0.3.3'`*) is: usr/local/include/curl... no need libcurl

>
> Ok, so let's get libcurl:
>
> $ sudo yum install libcurl
> Loaded plugins: fastestmirror, security
> Loading mirror speeds from cached hostfile
> * base: centos-mirror.jchost.net
> * epel: fedora-epel.mirror.lstn.net
> * extras: centos.mirror.lstn.net
> * updates: mirror.anl.gov
> Setting up Install Process
> No package libcurl available.
> Nothing to do
>

> Hmm, no package *libcurl* available. Alright, lets find it and install it

> Ok, apparently it's all over the place (*including some places I 'cp'ed it
> to*) but why won't it pick it up? I even downloaded the most up to date

[Robert R]

Thanks for your help guys!

I grabbed the latest curl, libcurl and libcurl-devel packages, but they fail to install, citing a libidn dependancy. So I grabbed libidn and libidn-devel but they also won't install, citing curl as the problem.

I think you may be right, and I should cut my losses and move to a different version / OS. So far 5.9 has been nothing but headaches.

Thanks again, I'll update if anything changes.

[Andrew Delaney]

Hi Forest,

Thanks for adding the info about updating curl on CentOS 5.9, you have saved me many more hours of going around in circles.

Regards,

Andrew.

On Thursday, April 25, 2013 3:44:21 AM UTC+1, Forrest Hawes wrote:

Hi Robert R!

I felt compelled to respond today, although its Wed, as I just read your post. I installed successfully  after pulling from Diaspora current git, on CentOS 5.9 over the last five days. Like you, I encountered lots of issues, and I thought I might give you a hand. As CentOS is not mentioned much, if at all, in the official wiki "Installation" section, I thought I might give some details of my experience the last five days, in hopes it might help you and others in the community.

I don't know if the webirc logs are archived yet, but Mr. ZYX helped me in the Diaspora forum -- #diaspora -- Monday morning (Pacific time) after I encountered the segmentation fault on libcurl and curl. When you have old versions of these, typhoeus will indeed segfault in Diaspora, for instance when clicking various 'edit' links. 

There appear to be a couple of threads that document this problem. Here is one: https://github.com/diaspora/diaspora/issues/3323

Although Mr. ZYX gave the requisite warning, and encouraged me to use something like the toast package manager, I was able to use the excellent repos at a  mirror of city-fan.org like this:

rpm -Uvh http://nervion.us.es/city-fan/yum-repo/city-fan.org-release-1-12.rhel5.noarch.rpm

and then yum install curl libcurl libcurl-devel.

After this, curl is quite up to date:

curl -V
curl 7.30.0 (i686-redhat-linux-gnu) libcurl/7.30.0 OpenSSL/0.9.8b zlib/1.2.3 c-ares/1.9.1 libidn/1.26 libssh2/1.4.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz

However, this is only part of the battle.

You have to recompile the gems against the new libcurl, of course. Since I installed ruby via .rvm and used Bundler with an install path like "bundle install --path vendor", I ultimately had to remove the entire ruby directory installed by "bundle install" like this:
(diaspora user home directory, in my case, is '/var/lib/diaspora')
diaspora# cd diaspora/vendor
diaspora# ls
diaspora# assets ruby
diapora# tar -cvf backup-my-ruby-bundled-gems.tar ruby/
diaspora# mv backup-my-ruby-bundled-gems.tar ~
diaspora# cd .. ; rm -rf vendor/ruby
diaspora# bundle install --path vendor

I had to do this to make bundler actually 'install' versus 'use' the gem resources previously installed. (People more versed in RoR deployments for Diaspora can correct my description, of course!)

do this after you update {curl|libcurl|libcurl-devel}, of course, and relaunch your server. You should no longer see this type of error.

Mr. ZYX and others extol the use of Arch Linux since you be "cutting-edge" and this problem will not occur for them. But some of us - myself, and you, and probably many others - have to work with virtual private server environments (mine was an OpenVZ container from a VPS provider, with about 2048 MB of RAM, give or take) in which the OS could only updated to the latest CentOS 5.9 (in my case). Here is `uname -r' and `cat /etc/redhat-release' on my Diaspora server:

-bash-3.2$ uname -r
2.6.32-042stab072.10
-bash-3.2$ cat /etc/redhat-release
CentOS release 5.9 (Final)
 
I had to do a number of things to make a workable environment. First, make sure that you are using 'yum-priorities'.  Second, you will want to control your Ruby, and Node.js as much as possible. I used the RVM method to install Ruby, in this case for the Diaspora user; likewise I used Pythonbrew to get a current 2.7.3 Python to install Node.js after failing to get a complete Python install when compiling from sources alone. (Ruby and Node.js are both pre-requisites for Diaspora, and Python version >= req. for Node.js to install).

Also, I removed the default Sendmail install, and used Postfix, dovecot, and kept the default cyrus-salsl. In my case the VPS provider blocks port 25, and therefore I configured Postfix to use the 'relayhost' setting, along with STARTTLS and a sasl_passwd hash file, and a good group of settings in the main.cf postfix file, to get a Postfix "smarthost" set up, sending Diaspora emails to the SMTP servers of my domain provider using the "submission" post, which is 587. Remember to edit the 'diaspora.yml' file Email Settings correctly -- don't forget that YAML is picky (spaces are important around the equals sign, and don't forget the quotes on values after the equals sign! Silly, but its important!)

I'm saying all this because you CAN get a successful Diaspora install, on CentOS 5.9 on a cheap OpenVZ container, with a lot of work!

I remember reading that some Diaspora devs use some CentOS-centric deployment tools, starts with an 's', its in the wiki somewhere.

Okay, that's all for now -- now I'm on to configuring Facebook & Twitter callbacks, and then on to skinning - so much fun...

Forrest Hawes
Techpraxic Systems