A script needs to support two servers, Fedora and Centos, with different versions of httpd (Apache). CFEngine is used to create the configuration file and it needs to put different sections to the file depending on which httpd version is installed in the system. How can I set a variable to true/false depending on which version is installed so that I can then generate the file appropriately? All the examples I could find only deal with installing, upgrading or removing packages.
You could use packagesmatching to get the version of httpd that's currently installed. You might combine it with ifelse, strcmp, regcmp so that you can set different variables and classes which you might use in your template.
I use CFEngine (3.9) on CentOS 7.3. This version sets a hard class centos. You can use this to create the different sections. (Is also sets a hard class redhat, because CentOS is a derived from RedHat). You can find the classes that are availabe on your system with:
cf-promises -v
Related
recently I tried to install an apache webserver on an ubuntu machine. I discovered two ways to do that.
The first one is to install it like it is described at this source apache docs using ./configure, make, make install to the downloaded apache sources.
And the second way is to install it via apt-get update && apt-get install apache2.
I also noticed that when I run the installation via apt-get it seems that there is a different configuration of the apache for example the directory /etc/apache2/* is only available over this way of installation. So when I install it manually the directories sites-available, sites-enabled, ... are just missing.
Is there also a way to get these folders when running the manual installation?
Where do this differences come from?
This is nothing that can be summed up in a few sentences. You basically ask: how does software management work under Linux systems? In short:
using the apt utility on a Ubuntu based system you are using the systems package management system, that should nearly always be what you want. That way the system can take care to keep your apache installation up to date, you can remove software again without leaving artefacts, the software is guaranteed to work with the system libraries already installed in your system. Potential conflicts are resolved. You can be certain that the configuration matches your system.
using the build system is a more generic (archaic) way: you do not only install the software, you build it from scratch from the software sources prior to installing it. That is only possible for OpenSource software, obviously. This certainly allows for more flexibility. But you are responsible yourself for a whole lot of things, starting with first setting up a complete build system, then configuring the package, select what you actually want to build and last but not least you are yourself responsible to update software you installed that way. This rarely is a good idea, with two exceptions:
you absolutely cannot find a pre build package for your Linux distribution or
you want to make own modifications to the software itself
The difference in the folder layout of the apache configuration is a separate thing. There are two aspects that come into play here:
you can change that layout using the uncounted build options offered by the build system (namely the options you can hand over to the configure utility on the command line).
typically the configuration of complex software packages (like the apache http server with all it's modules) is broken up into
various sub folders so that you can keep an overview and
allows additional packages to drop their additional configuration in place (this is mostly useful for prebuild packages)
Long story short: in 99,8% of all cases you want to use prebuild packages prepared for your distribution. That is the power of the software management systems under Linux (that still have no comparable counterpart in other operating systems).
I am required to install firebird super server on windows as a service, as a part of my application installation through wix for windows machines.
The machines might have a another firebird instance, usually default instance running, thus must be installed on a different port. User should not see any dialogues and installation should happen in the background.
I am able to do the installation through instsvc, installing firebird on a different port with a new instance name. However on windows you get the file execution security warning for instsvc execution. Thus I was looking in to http://www.mwasoftware.co.uk/firebird-msm merge modules but, it does not provide me with information on how to install on a different port/service name(if required).
Could you please provide me info on how to install firebird using wix, so that it would install firebird as apart of my wix installation, on a specified port, without obstructing existing installations, and no interaction from the user.
The Firebird installer only installs the service as the default instance with the default port. If you want to run on a different port and use a different servicename, then you need to change the port in firebird.conf yourself, and execute instsvc with an alternative servicename.
What I got from the merge module dev. While I havent tried the solution yet, seems to be straight forward.
The build scripts including WIX scripts are all available for
download. The direct link is:
http://www.mwasoftware.co.uk/download-msm/download/8-current-version/130-msm-build
To install a (possible) second server, you should do two things:
Build use a modified firebird.conf
Change all the UUIDs so that the package is unique.
You will also need to copy the build251.bat script and update the
environment variables to the Firebird version you are using. See also
readme.htm.
Problem
I want to both use stable versions of KRE and the bleeding edge nightly built KRE. One ASP.NET5 application may be beta2, but another I may want to be beta4. So what I did was install both in powershell as found here.
What happened is that the stable KVM installed in C:/Users/derp/.kre and the nightly build KVM installed in C:/Users/derp/.k
Worse yet, I can only see this now
Attempts
I tried kvm install KRE-CLR-x86.1.0.0-beta2 and it failed
Shall I try moving the packages from /kre file to the /.k file? This seems hacky and like a really bad idea
RTFM - Tried to use the install feature and including the -a, but failed.
I'm doing something the hard way and can't see the obvious.
I search on here
I feel if there is an answer to what I am trying to do above, it is worth being on here for others to find as well. Thank you all for your patience.
ASP.NET 5 is under development and there is no guarantee that changes between different pre-release version are backward compatible (sorry!).
The /.kre -> ./k rename is not backward compatible and you cannot have both the old and the new kvm simultaneously on the PATH. However, you can get can have two versions of kvm on your machine but you will have to use the full path for at least one of them.
I think the key is the path environment variable of your system. You have to use two set of "kvm", one for night builds, one for public beta, to download and set correct path environment variable.
For instance, I get one kvm from Entity Framework 7 repository, which can download and use beta 4 builds. I also have another kvm from Home repository which can download and use public beta builds.
You can use either kvm with "upgrade" or "use" command to set correct path environment variable, then run your application on the runtime you need. I think even Visual Studio 2015 CTP runs your projects based on the Runtime specified in your path environment variable. For the time being, only beta 3 run times can display in the project property dialog of VS 2015 CTP, but when hitting ctrl + F5, my website starts to load beta 4 runtime and assemblies, I can see the loading in output window, I think this is because I have .k folder prior to the .kre folder in the path environment variable.
Can you try the following?
$cmd-prompt>kpm Install KRE-CLR-x86
It worked for me.
I'm trying to build an embedded simple web browser for an embedded device and I've decided to use WebKit / WebKitGTK+. However, our device uses a Linux environment somewhat based on CentOS 5.8. I haven't been able to find any RPMS or mention of support for WebKit / WebKitGTK+ for CentOS 5.8 while doing several web searches.
Does anybody know if it's possible to build an older version of WebKitGTK+ such as 1.2.6-2.el6_0 which works well on CentOS 6.3? Are any RPMS available for CentOS 5.8?
The goal here is to be able to run a relatively current, at least 1.2.6 version of WebKitGTk on CentOS 5.8
Note: I was able to sort everything out. Just took a long time compiling all of the dependencies in the correct order with the correct options. I was able to get WebKitGTK 1.6.0 running on Centos 5.8.
You shouldn't have any problems building an old version of webkit if you can install the older versions of libraries that it requires.
If you have older or newer versions of GTK+ etc installed than the old version of webkit requires it may need quite a bit of porting to compile.
I'm not aware of any RPMs that meet your requirements
Depending on the compilation options you should be able to compile the dependencies in an isolated directory. With each library you typically use the --prefix option to specify the destination. Then when compiling something that depends on that library, you typically have an option to specify where to look for that library - something like --with-libraryname=/path/to/library. You want to check ./configure --help of each thing you're compiling to get the correct options.
It'll be quite a bit of work, but you should be able to compile everything you need into an isolated directory without replacing anything on the system. I would highly recommend you avoid doing this in root to ensure you have the right options.
I would like to install a complete new version of Trac alongside of our current version (0.11.7) and I am looking for ways to do this. After some research, it says to use python's virtualenv, but I am trying to find specific steps on how to accomplish this without interfering with our 0.11.7 version at all.
I am using Ubuntu as the OS. Any input including any possible pitfalls is appreciated.
Try virtualenvwrapper that makes using python-virtualenv a breeze.
The steps to create and use such a Python virtual environment are explained in the user documentation. These environments form the core setup of my own Trac plugin development. It allows to even use custom python versions, if you ever need that. I found the need to give each environment a self-explaining name and use it with different Trac environment directories matching the db version required by different Trac versions, i.e. virtualenv "trac-0.11_py2.4" with Trac env "sandbox_0.11", "trac-0.12_py2.6" with Trac env "sandbox_0.12", etc.