I have installed both Puppet master and agent on machines running CentOS 6
Everything went well, until the moment I have tried to deploy a simple sample module: I got an error, explained on the picture.
Trying to edit the file didn't help and the file was actually updated each time from repository
I tried running a different module which resulted in the same error
The error is because the formatting for Ruby code will not work with older Ruby. The CentOS 6 upstream Ruby package is 1.8.7, which is a super old Ruby version, and has been EOL for 3 years since 2014.
To fix this problem, Puppet started packaging Ruby and other dependancies as part of an all-in-one package since Puppet 4. This means there's no dependancy hell when it comes to EOL Ruby, OpenSSL and any other dependancies: they're all bundled and supported as a single RPM, without affecting the system packages.
It also means that you don't break any applications that require a different system Ruby, and generally makes using Puppet a lot easier.
Adding to this, the version of Puppet in CentOS is 3.X, which is also EOL. You should upgrade to Puppet 4. Here's a handy script that will install the Puppet 4 agent package on CentOS 6: https://github.com/petems/puppet-install-shell
If you are limited to using Puppet 3 for whatever reason, there are a few less preferable solutions:
Download a new Ruby RPM for CentOS 6, (such as from this Github repo) or a CloudPackage.io repo (such as this one I made for CentOS 6 Ruby packages https://packagecloud.io/petems/ruby2/install)
Disadvantage: Those RPMs are not supported officially and might have unintentional issues
Fork the module to change the Ruby code
Disadvantage: This is a big maintenance cost, and you'll have to do this every time an update happens to the module upstream.
Related
We are in transition from Puppetmaster 3.8 to Puppet server(OpenSource) 5.3.
As a prerequisite for Puppetserver 5.3 installation requires Java 8 runtime packages. Can we install Adopt-OpenJDK with Pupperserver 5.3?
Puppetserver runs just fine on OpenJDK, but I strongly recommend that you run the server on an officially-supported platform (RHEL, CentOS, Debian, Ubuntu, or SLES), and use one of Puppet, Inc.'s official packages for that system. These each express a dependency on an appropriate Java 8 package, and they will configure Puppet properly to work in conjunction with that implementation. On the platforms for which I have knowledge of the details, it is the distro's OpenJDK build that is used.
It should be possible to [re]configure Puppetserver to use an Adopt-OpenJDK implementation of the Java 8 runtime, but this is swimming upstream.
Thanks John.Adding one more point here puppetserver has a dependency on openjdk-8-jre-headless:amd64.But adopt open jdk is not providing headless package.So we suspect this may cause issue as puppetserver will look for the headless package.
When I run puppet agent -t on my server I get an error:
The logs from the puppet-master look like this:
Unfortunately, this is an error caused by using Ruby 1.8.7, a long EOL version of Ruby. Puppet uses Ruby to compile catalogs, and CentOS 6's upstream uses 1.8.7 Ruby, which has been EOL for 3 years.
The easiest way to fix this problem is to use Puppet 4 onwards, which packages it's own Ruby as part of the all-in-one package (to avoid errors like this on systems that support older Ruby versions)
I have an rpm compiled in centos 5.x which requires libnetsnmp.so.10 and other shared objects. I want to create an rpm of it which is to be run on centos 6.x but it fails to install as on installation it says :
error: Failed dependencies:
libnetsnmp.so.10()(64bit) is needed and so on...
But Centos 6.x contains libnetsnmp.so.20
So I created symbolic links of libnetsnmp.so.10 of libnetsnmp.so.20.
But problem is still the same.
So can you please help me to resolve this problem?
If recompiling for Centos 6 isn't an option, you can try two things, first, install the correct libnetsnmp in the Centos 6 server. If that's not an option, you can add the following to your RPM spec file:
Autoreq: no
This will cause it not to scan your binary for dependencies (such as dynamically linked libraries), and automatically build that into the RPM.
Of course, if that version of libnetsnmp is ACTUALLY required, your just hosing yourself down the road, but likely newer versions will work just fine.
I have a project that runs on Debian and uses many packages provided from the Debian repositories.
Because of demand, I've looked into porting the project to CentOS, but found that many of the packages I require are completely missing - at least 10 dependencies would have to be compiled manually at install time on the users machine.
My question is, what is the best way to create an installer for the user's machine? Should I use automake tools (with the standard ./configure, make, make install), to compile the required libraries, or is this a non-standard approach. Note that my app doesn't actually need to be compiled since it is written in Python, so is it weird to do a "make", when you're not compiling your own app?
Should the configure script just warn the user that package X is missing, and let them handle the rest?
Should I roll my own dependency checker by runng pkg-config manually a few times for each library required, and exit if something is missing?
I'm quite new to this, so any tips to get me moving in the right direction are appreciated.
Edit: I am familiar with RPM and yum for red hat base distros, but CentOS is missing many multimedia packages that I require. An example of one of my package dependencies is "liquidsoap" which is a programmable audio engine: http://savonet.sourceforge.net/
This is available on Debian, but not Redhat/Centos
See this link on CentOS package management.
http://wiki.centos.org/PackageManagement/Yum
CentOS is redhat based and does not use .deb packages by default. However apt package management has been ported to tons of platforms, you may be able to use a port for centOS
If you use YUM whatever packages you need will be there for your application as redhat distros need all the same things that any other distro does.
EDIT: To get the details out of comments
Packages not available on the target platform either have to be built (possibly as a port) on the target platform and then shipped in the ported package (in this case YUM), or code needs to be modified and forked to use packages which already are available on the target platform. The choice depends on which is worse, or which is even possible given your constraints.
I am trying to get Mercurial to be hosted via "hgweb.cgi" on IIS 7.5. I have everything configured according to http://www.jeremyskinner.co.uk/mercurial-on-iis7/ except for that I installed python 2.6 and Mercurial 1.7.3. When I try to go to the hgweb.cgi script, I get the following error:
"No module named osutil"
After a bit of searching, I've found that I need to install the python-dev packages, but that seems to only apply to unix. Is there anything else I need to get this working on windows?
Thanks.
Note that I tried the mercurial binaries/library.zip on both both HgTortoise and the Mercurial x86 installer available here:
https://www.mercurial-scm.org/downloads
(Mercurial 1.7.3 Inno Setup installer - x86 Windows - does not require admin rights)
I had the same issue trying to re-create an HgWeb server with Mercurial 2.1.1. I posted a question on the Mercurial mailing list.
Because HgWeb requires Python, you have to get Mercurial as a Python module. Fortunately, the Mercurial folks supply one; it's tagged py2.6 with the description
installs Mercurial source as Python modules and thus requires Python 2.6 installed. This is recommended for hgweb setups
Once I ran that installer, HgWeb started working.
Looking at the available downloads and the version specified in the question, it looks like you might have installed TortoiseHg 1.1.8 with Mercurial 1.7.3, which is probably missing some python packages.
I've been researching this problem myself (except I'm trying to run Mercurial via ISAPI), and it appears 1.7.1 is the last version that works with IIS due to dependency problems with msvcr90.dll in all later versions, including the newly released 1.8.2.
See this issue, which ultimately seems to be caused by this still open 1-year-old Python issue.
Judging by the conversation, a fix is not easy. I know of no workarounds, so I am forced to use 1.7.1 in the meantime.
Edit: CGI works with 1.8.2 though, so the above issue seems to only affect running Mercurial through ISAPI.