On my RedHat 7.4, I'm creating an RPM with CMake, and one of the instructions I want to give the RPM is - to leave a certain config file alone, in case the action is an upgrade.
I thought I could accomplish this in my CMakeLists.txt with (mcve):
cmake_minimum_required(VERSION 3.4.0 FATAL_ERROR)
project(MyKibana)
set(kibana_version 6.2.2)
set(kibana_dir /usr/share/mykibana)
list(APPEND CPACK_RPM_USER_FILELIST
"%config(noreplace) ${kibana_dir}/config/kibana.yml"
)
However, when I do sudo yum upgrade /tmp/my-kibana-6.2.2-577-g7cca696.el7.my.x86_64.rpm -y, I see that the file at /usr/share/mykibana/config/kibana.yml is overwritten with the file in the RPM.
Is there something else I need to do besides the %config(noreplace) directive?
The behavior of rpm with config files is rather complicated to understand.
%config(noreplace) will not replace your config file if you changed it. If you did not touch the config file, it will always be overwritten with the new config file.
For a more thorough understanding; see this excellent page: http://people.ds.cam.ac.uk/jw35/docs/rpm_config.html
Related
I'm trying to load and unload modules using modprobe but I'm having problems. The command fails with "modprobe:
can't change directory to '/lib/modules': no such file or directory"
There is actually no /lib/modules directory on the image at all.
PS : I used yocto project to build Linux os image and I'm using the 3.14 kernel.
Any help would be appreciated!
Probably you just don't have any modules installed. Add
IMAGE_INSTALL += "kernel-modules"
to your image recipe.
Update:
If this does not add the modules to the image, your next steps to check are:
Check if there actually any modules built. Not all kernel configurations actually do this. An easy way is to look into the tmp/deploy/... directory that holds your generated packages.
Check if the setting actually gets propagated to the iamge. bitbake -e on your image will tell, grep for IMAGE_INSTALL.
Update 2:
For 1) All built kernel-modules are automatically packaged in packages starting with "kernel-module-". So if there is no package bearing that prefix and the module name you expect, then its not a problem of installing, but a problem of your kernel or kernel config not building the module at all.
For 2) "I can't read it all": Thats why I explicitly said "grep for IMAGE_INSTALL" - you shall not read it all, just see if that variable actually includes "kernel-modules".
Well I found the solution:
In fact
IMAGE_INSTALL += "kernel-modules"
Does not add modules folder under /lib . It does not work wiTh YOCTO PROJECT SUMO release. I added this
CORE_IMAGE_EXTRA_INSTALL += " kernel-modules"
to my local.conf and now the /lib/modules is found and kernel-modules are packaged
I have set up a local Perl web environment on my Windows machine. The application I'm working on is originally from a Linux server, and so the shebang for source .pl files look like so:
#!/usr/bin/perl
This causes the following error on my Windows dev machine:
(OS 2)The system cannot find the file specified.
Is it possible to change my Apache 2 conf so that the shebang is ignored on my Windows machine? Of course I could set the shebang to #!c:\perl\bin\perl.exe, that much is obvious; but the problem comes to deploying the updated files. Clearly it would be very inconvenient to change this back on each deploy. I am using ActivePerl on Windows 7.
Update:
I should have mentioned that I need to keep the shebang so that the scripts will work on our shared hosting Linux production server. If I did not have this constraint and I didn't have to use the shebang, the obvious answer would be to just not use it.
I use #!/usr/bin/perl in my scripts and configure Apache on Windows to ignore the shebang line. Add
ScriptInterpreterSource Registry-Strict
to your httpd.conf and set up the Windows Registry key as explained in the Apache docs.
Here is what I get when I export the key:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\.pl\Shell\ExecCGI\Command]
#="c:\\opt\\perl\\bin\\perl.exe"
I have been using this setup with Apache and ActiveState Perl on my Windows laptop and the Apache and Perl distributions that come with ArchLinux on my server.
The Apache docs (to which I linked above) state:
The option Registry-Strict which is new in Apache 2.0 does the same thing as Registry but uses only the subkey Shell\ExecCGI\Command. The ExecCGI key is not a common one. It must be configured manually in the windows registry and hence prevents accidental program calls on your system. (emphasis mine)
There is no portable shebang line. Even on the same platform and architecture, someone might have installed perl is a different location.
The trick is to not install modules and scripts by hand. When you package everything as distributions and use the module toolchain, the shebang lines are modified automatically to point to the perl you used to install everything. You shouldn't have to think about these details. :)
I use #! /usr/bin/env perl as the shebang on all of my perl, whether on *nix or Windows. Windows just ignores it, and the Unixen follow env to the chosen perl disto.
The way I had this working was to copy perl.exe to c:/usr/bin/ and rename it to perl (strip the .exe)
In win7 and up you can also do this with the "dos" command mklink.
Start a cmd shell as administrator and do something like the following:
mklink /d c:\usr c:\Perl # Activestate perl in c:\Perl\bin\perl.exe
mklink /d c:\usr c:\xampp\perl # Xampp perl in c:\xampp\perl\bin\perl.exe
Install any Windows Bash flavor (such as Cygwin, MSYS2 or GnuWin32);
Create a trivial redirecting shell script:
exec "#"
Create a registry entry:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\.cgi\Shell\ExecCGI\Command]
#="<path-to-sh> <path-to-script>"
[HKEY_CLASSES_ROOT\.pl\Shell\ExecCGI\Command]
#="<path-to-sh> <path-to-script>"
[HKEY_CLASSES_ROOT\.py\Shell\ExecCGI\Command]
#="<path-to-sh> <path-to-script>"
(...and so on.)
Jot in your httpd.conf file:
ScriptInterpreterSource Registry
Apache will now resolve Unix shebangs relative to the interpretation given by your choosen Bash flavor. This gives much more flexibility than hardcoding interpreter paths in the registry.
I don't have Windows handy, but perlcritic says:
my $desc = q{Found platform-specific perl shebang line};
my $expl = q{Perl source in parrot should use the platform-independent shebang line: #! perl};
So, I guess #! perl should work.
Edit: doesn't work on linux; apparently works in parrot, although I don't see how they manage that.
How to use Linux shebang (#!/usr/bin/perl) when running Perl based web-site with {site-name} on localhost in Windows 10?
This works for me:
XAMPP on localhost\{site-name} (C:\xampp\htdocs\{site-name})
independently installed Strawberry Perl (C:\Perl\perl\bin) because Perl included in XAMPP package is not satisfactory
In default configuration you must use this shebang:
#!C:\perl\perl\bin\perl.exe -IC:\xampp\htdocs\{site-name}
Is it possible to include directory (after -I switch) permanently to #INC?
Yes, you can do it by setting the PERLLIB or PERL5LIB environment variables. This works when running perl script from command line, but surprisingly it is ignored by apache server in XAMPP. However one of #INC directories (C:/Perl/perl/site/lib) is usually empty so you can make symbolic link to your web-site directory:
mklink /D c:\perl\perl\site\lib C:\xampp\htdocs\{site-name}
Now, you can use this shebang:
#!C:\perl\perl\bin\perl.exe
Moreover, you can create directory c:\usr\bin
md c:\usr\bin
and copy perl.exe from C:\perl\perl\bin\
copy C:\perl\perl\bin\perl.exe c:\usr\bin\perl.exe
(Another mklink trick is not working here from some reasons.)
Finally, you can use Unix-styled shebang on Windows:
#!/usr/bin/perl
I am developing a library which uses CMake to control it. It would be good to provide a "FindXXX.cmake" which locates the library and header files. This file would enable the users to use the command "find_package(XXX)" to find my library.
However, I don't know how to install my lib's "FindXXX.cmake" to an correct location. I failed to find a CMake's build-in mechanism to install a "FindXXX.cmake". In addition, CMake's variable "CMAKE_MODULE_PATH" is a list of directories, so I cannot install according to that vairable because I cannot decide which specific directory to use.
If the copy of CMake is installed to a standard location(i.e. use no prefix etc) then this can be done by placing the file in /usr/share/cmake/Modules/ directory.
If you are going to supply a bundle probably you can add some commands to check if the cmake is available. if yes you can check for cmake --system-information|grep _INCLUDED_SYSTEM_INFO_FILE value from that to get modules directory.
Otherwise there's no way you can do that.
A workaround can be done i.e. if there is a binary in your bundle then you can add a command line option for placing this file.
I get the following error in Terminal when I try to install mod_perl:
Please tell me where I can find your apache src
[../apache_x.x/src]
I've tried using cpan > install mod_perl(even forcing v. 2) AND I've tried just downloading it, and doing $ perl Makefile but they both lead to the same error.
I'm trying to follow steps from http://bulknews.net/lib/mod_perl_guide/install.html or Oreilly's CGI Programming with Perl but the site says:
The first thing first is to download the Apache source code and unpack it into a directory -- the name of which you will need very soon
Mac comes with Apache, which is why I don't want to download it. But how can I find the apache src???
Update: Haven't checked, but did find apache2 folder in ~/private/var/log
Additional Info --- separate locations of mod_perl files:
I have an unzipped folder: mod_perl-1.31 in my ~/Downloads folder. (for manual install)
I found tar.gz files of mod_perl -1 and -2 in ~/G/GO/GOZER/mod_perl-1.31.tar.gz (or 2.04) (for cpan)
Should I delete these?
Let me know if there is any other info required to solve this, or if I somehow missed a post with this same question. Thanks a lot.
It's quite possible that Mac OS X doesn't ship with the apache source code (I'll be damned if I can find it.) I can find no references to it online or on my machine.
I am going to ignore the built-in Apache installation and install my own. This article discusses PHP and Apache on Mac OS X but I'll also be using mod_perl on my system and will adjust as necessary: http://www.phpied.com/installing-php-and-apache-on-mac-osx-that-was-pretty-easy/
Install it dynamically as a dso.
https://perl.apache.org/docs/2.0/user/install/install.html#Dynamic_mod_perl
As part of our product release we ship Apache HTTP Server binaries that we have compiled on our (UNIX) development machine.
We tell our clients to install the binaries (on their UNIX servers) under the same directory structure that we compiled it under. For some clients this is not appropriate, e.g. where there are restrictions on where they can install software on their servers and they don't want to compile Apache themselves.
Is there a way of compiling Apache HTTP Server so its installation location(s) can be specified dynamically using environment variables ?
I spent a few days trying to sort this out and couldn't find a way to do it. It led me to believe that the Apache binaries were hard coding some directory paths at compilation preventing the portability we require.
Has anyone managed to do this ?
I think the way to do(get around) this problem is to develop a "./configure && make" script that your client uses to install, specify and compile the binaries. That would offcourse require that the client has all the source-code installed on his server or you can make it available on an NFS share.
If you are compiling Apache2 for a particular location but want your clients to be able to install it somewhere else (and I'm assuming they have the same architecture and OS as your build machine) then you can do it but the apachectl script will need some after-market hacking.
I just tested these steps:
Unpacked the Apache2 source (this should work with Apache 1.3 as well though) and ran ./configure --prefix=/opt/apache2
Ran make then sudo make install to install on the build machine.
Switch to the install directory (/opt/apache2) and tar and gzip up the binaries and config files. I used cd /opt/apache2; sudo tar cf - apache2 | gzip -c > ~/apache2.tar.gz
Move the tar file to the target machine. I decided to install in /opt/mynewdir/dan/apache2 to test. So basically, your clients can't use rpm or anything like that -- unless you know how to make that relocatable (I don't :-) ).
Anyway, your client's conf/httpd.conf file will be full of hard-coded absolute paths -- they can just change these to whatever they need. The apachectl script also has hard coded paths. It's just a shell script so you can hack it or give them a sed script to convert the old paths from your build machine to the new path on your clients.
I skipped all that hackery and just ran ./bin/httpd -f /opt/mynewdir/dan/conf/httpd.conf :-)
Hope that helps. Let us know any error messages you get if it's not working for you.
I think the way to do(get around) this problem is to develop a "./configure && make" script that your client uses to install, specify and compile the binaries. That would offcourse require that the client has all the source-code installed on his server or you can make it available on an NFS share.
Not to mention a complete build toolchain. These days, GCC doesn't come default with most major distributions. Wouldn't it be sane to force the client to install it to /opt/my_apache2/ or something like that?
#Hissohathair
I suggest 1 change to #Hissohathair's answer.
6). ./bin/httpd -d <server path> (although it can be overridden in the config file)
In apacheclt there is a variable for HTTPD where you could override to use it.