I can see the yum variables as on Redhat page at Redhat docs
The variable $releasever resolves to 6Server or 7Server etc
Is there any default variable which can resolve to just 6 or 7
Thanks,
For RedHat 6Server and 7Server are the values that matter as far as I know.
I don't believe 6 and 7 don't mean anything in RH land (they do for CentOS though).
So I would doubt that there's anything built in for them.
But you can add a custom variable yourself easily enough by dropping a file in /etc/yum/vars/ and using its name as the variable.
So echo 6 > /etc/yum/vars/barever and then use $barever in the yum configuration.
Related
I have installed PostgreSQL 13 on windows 10
When I tried to run this command:
$ which Postgres on Git Bash, It returns which: no Postgres in (/c/Users*ahmedeid/......
Could you help me solve the issue?
It seems that your PostgreSQL installation's bin directory is not on the PATH, so you cannot find the server executable.
You'll have to modify the PATH environment variable appropriately.
Another possibility is that your bash was already running when you installed PostgreSQL, so that its PATH setting is out of date. Try closing bash and start a new one. Maybe that one has the correct setting.
I have run into an interesting problem. I am compiling my application code and was using ace library(version 6_1_1) on my centos 6 machine. Everything worked fine. When i look at the symbols of the ace library compiled on centos 6 machine, it looks like this:
bash-4.1$ nm ace/libACE.so.6.1.1 | grep handle_sig 000f9430 T
_ZN15ACE_Sig_Adapter13handle_signalEiP7siginfoP8ucontext 000b84d0 T _ZN17ACE_Event_Handler13handle_signalEiP7siginfoP8ucontext 00079f10 T _ZN18ACE_Service_Config13handle_signalEiP7siginfoP8ucontext 000f26d0 T _ZN19ACE_Process_Manager13handle_signalEiP7siginfoP8ucontext 0007ee70 T _ZN19ACE_Service_Manager13handle_signalEiP7siginfoP8ucontext
000cf920 T
_ZN20ACE_MMAP_Memory_Pool13handle_signalEiP7siginfoP8ucontext 000f8b80 T _ZN22ACE_Shared_Memory_Pool13handle_signalEiP7siginfoP8ucontext
bash-4.1$
But when i compile the same project on centos 7 machine, the symbols change:
bash# nm ace/6_1_1/ace/libACE.so.6.1.1 | grep handle_sig 000fa090 T
_ZN15ACE_Sig_Adapter13handle_signalEiP9siginfo_tP8ucontext 000b9570 T
_ZN17ACE_Event_Handler13handle_signalEiP9siginfo_tP8ucontext 0007e070 T
_ZN18ACE_Service_Config13handle_signalEiP9siginfo_tP8ucontext 000f3500 T
_ZN19ACE_Process_Manager13handle_signalEiP9siginfo_tP8ucontext 00081cb0 T
_ZN19ACE_Service_Manager13handle_signalEiP9siginfo_tP8ucontext 000d1990 T
_ZN20ACE_MMAP_Memory_Pool13handle_signalEiP9siginfo_tP8ucontext 000f93d0 T
_ZN22ACE_Shared_Memory_Pool13handle_signalEiP9siginfo_tP8ucontext bash#
Notice that there is an extra _t in siginfo. So, my application which links this library fails to launch during run time giving me that error:
symbol "_ZN17ACE_Event_Handler13handle_signalEiP9siginfo_tP8ucontext"
not found
Another interesting point to note is that if i copy the compiled ace library from my centos 6 box into centos 7 box, my application works fine.
I am lost on how to fix this issue. Any help in this regards will be appreciated!
But when i compile the same project on centos 7 machine, the symbols change:
Probably Glibc on Centos 7 has changed one of the types in public headers which caused mangler to emit different symbols:
$ echo _ZN15ACE_Sig_Adapter13handle_signalEiP7siginfoP8ucontext | c++filt
ACE_Sig_Adapter::handle_signal(int, siginfo*, ucontext*)
$ echo _ZN15ACE_Sig_Adapter13handle_signalEiP9siginfo_tP8ucontext | c++filt
ACE_Sig_Adapter::handle_signal(int, siginfo_t*, ucontext*)
Notice that new method now uses siginfo_t rather than siginfo (you'll see hundreds of complaints if you google for "siginfo_t vs siginfo").
Another interesting point to note is that if i copy the compiled ace
library from my centos 6 box into centos 7 box, my application works fine.
That's backward compatibility - you can (usually) run apps linked on older version of distro on it's newer versions.
On the contrary, forward compatibility (in your case - linking old application against new library) is not guaranteed.
I am lost on how to fix this issue.
If you are only interested in new CentOS - rebuild all your code. If you want to run on older versions - build on the oldest and distribute that.
I’m currently running window 7, ACF 11, and IIS 7 and would like to install Lucee express to try.
I’m having the hardest time getting Lucee to work on my local desktop. I followed this article http://www.gpickin.com/index.cfm/blog/setting-up-lucee-in-my-dev-environment-changing-ports I can’t get the Lucee welcome page to work.
I download the Lucee Express from here http://lucee.org/downloads.html
I extract the file to C:\lucee
Ran the C:\lucee\bin\startup.bat
Navigated to 127.0.0.1:8888
I get the follow message: Firefox can't establish a connection to the server at 127.0.0.1:8888
Can someone tell me what am I doing wrong? Thank you in advance for your insights.
As identified in the comments on the question: you are missing the environment variable pointing to your Java runtime (you need one of JAVA_HOME or JRE_HOME.
This can be achieved in one of a coupla ways.
Set it globally:
Control Panel > System > Advanced system settings > Environment Variables > System Variables > New...
Or set it for just that environment by editing the startup.bat file you've already been using:
SET JAVA_HOME=[path]
In both situations you need a path to either a JRE or a JDK. You say you have CF11 already installed, so you can simply point to its one, which will be a subdirectory of your CF install, as Leigh points out above. So something like:
SET JRE_HOME=D:\apps\Adobe\ColdFusion\11\express\jre
If you have a Java JDK installed instead and want to use that, use JAVA_HOME instead of JRE_HOME, eg:
SET JAVA_HOME=D:\apps\Oracle\Java\jdk\1.8.0_60
As these things can be installed anywhere, you'll just need to locate 'em and use the path accordingly. You want to point it to the top level directory of your JRE or JDK, which contains the bin subdirectory.
I googled it up and read through but did'nt find any answer. I am using cfengine-community 3.5 version on ubuntu.
You can create different subdirectory trees for each of the versions of Ubuntu that you're dealing with; i.e.:
/data/cfengine3/data/ubuntu-13.04
/data/cfengine3/data/ubuntu-14.04
...
Then define one class per version of Ubuntu (ubuntu_13_04, ubuntu_14_04...) and execute the copying of files of one subdirectory or the other, depending on the class that is defined.
We do it like this, because we still have a small set of servers with CentOS 5.
Apache Tomcat 7.0, CentOS 5.8 i386
A web application needs a specific environment variable XY to be present in its context.
This variable is set in /etc/profile as a result of a computation (i.e. not a static value) and it is also used by other native applications running on the same system (hence it has to be the environment variable approach).
Tomcat is started with a general script using a dedicated tomcat user and sudo.
The first problem of passing XY through sudo is solved (thanks to stackoverflow) with the explicit definition within /etc/sudoers:
Defaults env_keep ="XY"
It means that the environment variable XY is preserved by sudo which is not the default case.
Now the environment variable XY is visible in the tomcat process. This can be verified with ps and /proc/tomcat-PID/environ or an explicit echo $XY in */your_tomcat/bin/startup.sh* (which is called by the init.d script using sudo). But seeing XY in the tomcat process does not mean the web app can see it. The web app dumps its environment to the log file with help of
LOGGER.debug("Environment: " + System.getenv());
the astonishing result for me was: no XY at all, although tomcat had it!
After reading the context documentation of tomcat 7.0 (be careful to distinguish between 7.0 and older versions of tomcat) I added the following entry to */your_tomcat/conf/context.xml*:
<Context>
...
<Environment name="XY" value="INIT_VALUE" type="java.lang.String"/>
...
</Context>
Now the output of System.getenv() really contains my XY environment variable BUT it has the correct value from /etc/profile not the value INIT_VALUE I specified in context.xml. With other words my /etc/profile does overwrite the INIT_VALUE, which is what I needed but not what I expected as there is no word about this in the documentation.
Did I find un-docmented behaviour that might be removed in later versions of tomcat or is this the way to go?
So in the end I am happy having a working solution but I am not very confident that this is a recommended and proper way of passing-through environment variables.
Any comments would be highly appreciated.
Tomcat Environment entries are different from system environment variables. Environment Entries specified by <Environment> markup are JNDI, accessible using InitialContext.lookup under java:/comp/env, while System.getEnv() is about system environment variables (of the tomcat process itself).