I wrote a .spec file on RHEL and I am building RPM using rpmbuild. I need ideas on how to handle the situation below.
My RPM creates an empty logs directory when it installs first time within the installation folder like below
/opt/MyInstallation-1.0.0-1/some executables
/opt/MyInstallation-1.0.0-1/lib/carries shared objects(.so files)
/opt/MyInstallation-1.0.0-1/config/carries some XML and custom configuration files(.xml, etc)
/opt/MyInstallation-1.0.0-1/log--->This is where application writes logs
When my RPM upgrades MyInstallation-1.0.0-1, to MyInstallation-1.0.0-2 for example, I get everything right as I wanted.
But, my question is how to preserve log files written in MyInstallation-1.0.0-1? Or to precisely copy the log directory to MyInstallation-1.0.0-2.
I believe if you tag the directory as %config, it is expected that the user will have files in there, so it will leave it alone.
I found a solution or workaround to this by hit and trial method :)
I am using rpmbuild version 4.8.0 on RHEL 6.3 x86_64. I believe it will work on other distros as well.
If you install with one name only like "MyInstallation" rather than "MyInstallation-version number-RPM Build Number" and create "logs directory as a standard directory(no additional flags on it)[See Original Question for scenario] Whenever you upgrade, you normally don't touch logs directory. RPM will leave its contents as it is. All you have to do is to ensure that you keep the line below in the install section.
%install
install --directory $RPM_BUILD_ROOT%{_prefix}/%{name}/log
Here, prefix and name are macros. That has to do nothing with underlying concept.
Regarding config files, the following is a very precise table that will help you guarding your config files. Again, this rule can't be applied on logs our applications create.
http://www-uxsup.csx.cam.ac.uk/~jw35/docs/rpm_config.html
Thanks & Regards.
Related
We manage systems and thus manage repositories. We remove repositories which we do not use, present in /etc/yum.repos.d/<file>
Our problem is: after an update/upgrade of the system, CentOS automatically re-creates the repositories which were removed, which is an issue for us.
Question: Is there a command / method to ensure repositories are not re-created after an upgrade on CentOS 7 systems.
Those repositories are created by someone, the OS doesn't recreate them.
Either they are restored by an update of a RPM package such as centos-release or by an automatic script you setup/run (ansible?).
I'm not aware of an automatic method to delete a repo; I see a couple of solutions:
Exclude centos-release from the upgradable packages, by adding
exclude=centos-release
to /etc/yum.conf (space separated list), but this could break some updates;
Disable them with:
# yum-config-manager --disable base,updates,extras,centosplus,epel,whatever
(this can be easily scripted and put in a cron or in your ansible playbook)
Write a small script and place it in /etc/cron.hourly/, e.g. /etc/cron.hourly/wipe_repos, containing:
#!/usr/bin/env bash
rm -f /etc/yum.repos.d/CentOS-Base.repo
or, better:
#!/usr/bin/env bash
yum-config-manager --disable base,updates,extras,centosplus,epel,whatever
I would suggest to use solution 2, since the repo files aren't overwritten by updates, but the new versions are placed along the old in .rpmnew files.
This is guaranteed by the flag %config(noreplace) in the source rpm of centos-release, applied to all files in /etc/yum.repos.d/.
You can check this by downloading the .src.rpm and opening the centos-release.spec file.
$ mkdir test && cd test
$ yumdownloader --source centos-release
$ rpm2cpio centos-release*.rpm | cpio -idmv
$ cat centos-release.spec
(or search for the package online and download the src.rpm)
Then scroll down to section %files and you'll notice:
%config(noreplace) /etc/yum.repos.d/*
%config(noreplace) means that all those files are not replaced with new files from an update, but the files from the new rpm are saved with the extension .rpmnew, so you'll have:
$ ls /etc/yum.repos.d/
CentOS-Base.repo <-- here you set them as disabled
CentOS-Base.repo.rpmnew <-- this comes from the update, but yum will ignore it
For reference, see http://people.ds.cam.ac.uk/jw35/docs/rpm_config.html or https://serverfault.com/a/48819/.
As I already said in the comments below the question, the reason why those repositories keep reappearing after an update is quite simple: the files defining the system repositories are owned by the package centos-release and whenever this package gets updated or reinstalled, the repositories reappear.
The package centos-release is a very basic package, it provides the capabilities redhat-release and system-release, and a number of other basic packages depend on it.
[local ~]$ rpm -q --provides centos-release
centos-release = 7-6.1810.2.el7.centos
centos-release(upstream) = 7.6
centos-release(x86-64) = 7-6.1810.2.el7.centos
config(centos-release) = 7-6.1810.2.el7.centos
redhat-release = 7.6-1
system-release = 7.6-1
system-release(releasever) = 7
[local ~]$ rpm -q --whatrequires system-release
setup-2.8.71-10.el7.noarch
grubby-8.28-25.el7.x86_64
[local ~]$ rpm -q --whatrequires redhat-release
initscripts-9.49.46-1.el7.x86_64
systemd-219-62.el7_6.5.x86_64
There is no easy way out of this.
But one possible solution might be to create a customized RPM package to replace centos-release. It should contain the pointers to your own repositories and of course needs to provide the capabilities redhat-release and system-release.
Please be aware that I have no idea if this is actually going to work, it's just something that came to my mind while thinking about the problem. It might save you the work of creating a full custom distribution derived from CentOS, which is the only other way I can think of to achieve what you seem to want.
My solution doesn't exactly solve the problem you request ("how do I delete default repository config files forever?"), but it does stabilize your config changes. If you zero out the files instead of deleting them, then system updates will leave your 'edited' versions unchanged.
I do feel that this is a 'hack', leaving named ghost files, but it's one I can live with. No need to disable or customize redhat-release or system-release.
My problem was slightly different than yours - I maintained different configs for the same repositories for different situations, indicated by filename. On updates the original files would return, leaving me with redundant and incorrect definitions. Now they don't.
I'm interested in learning about kde environment. So I read the contribution page on wiki, git cloned the kompare repo and built it. But an attempt to execute the binary gave me an error saying Could not load our KompareNavigationPart. The console showed the following error about kservice:
> ./kompare
kf5.kxmlgui: cannot find .rc file "kompareui.rc" for component "kompare"
kf5.kservice.services: KMimeTypeTrader: couldn't find service type "Kompare/ViewPart"
Please ensure that the .desktop file for it is installed; then run kbuildsycoca5.
kf5.kxmlgui: cannot find .rc file "kompareui.rc" for component "kompare"
Aborting aboutToFinish handling.
I couldn't find anything about it in the readme or the project wiki. I've installed the kde-development-meta package on arch linux. Can anyone help me get started with development on kde platform?
Short answer: Use "cmake -DCMAKE_INSTALL_PREFIX=/usr" and "make install".
Long answer: It looks like you tried to run from the build directory, but the KDE plugin loader does not look there by default. You could adjust the various path variables to additionally point to your build directory. The variables are mentioned at https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source#Set_up_the_runtime_environment
You can also use "make install" to install to a run-time directory. If you did not change the defaults of cmake via -D option, this will be "/usr/local/", and in this case you also have to adjust the various path variables to include that directory, unless your distribution already configured this for you.
I followed the Software Collections Quick Start and I now have Python 3.5 installed. How can I make it always enabled in my ~/.bashrc, so that I do not have to enable it manually with scl enable rh-python35 bash?
Use the scl_source feature.
Create a new file in /etc/profile.d/ to enable your collection automatically on start up:
$ cat /etc/profile.d/enablepython35.sh
#!/bin/bash
source scl_source enable python35
See How can I make a Red Hat Software Collection persist after a reboot/logout? for background and details.
This answer would be helpful to those who have limited auth access on the server.
I had a similar problem for python3.5 in HostGator's shared hosting. Python3.5 had to be enabled every single damn time after login. Here are my 10 steps for the resolution:
Enable the python through scl script python_enable_3.5 or scl enable rh-python35 bash.
Verify that it's enabled by executing python3.5 --version. This should give you your python version.
Execute which python3.5 to get its path. In my case, it was /opt/rh/rh-python35/root/usr/bin/python3.5. You can use this path to get the version again (just to verify that this path is working for you.)
Awesome, now please exit out of the current shell of scl.
Now, lets get the version again through this complete python3.5 path /opt/rh/rh-python35/root/usr/bin/python3.5 --version.
It won't give you the version but an error. In my case, it was
/opt/rh/rh-python35/root/usr/bin/python3.5: error while loading shared libraries: libpython3.5m.so.rh-python35-1.0: cannot open shared object file: No such file or directory
As mentioned in Tamas' answer, we gotta find that so file. locate doesn't work in shared hosting and you can't install that too.
Use the following command to find where that file is located:
find /opt/rh/rh-python35 -name "libpython3.5m.so.rh-python35-1.0"
Above command would print the complete path (second line) of the file once located. In my case, output was
find: `/opt/rh/rh-python35/root/root': Permission denied
/opt/rh/rh-python35/root/usr/lib64/libpython3.5m.so.rh-python35-1.0
Here is the complete command for the python3.5 to work in such shared hosting which would give the version,
LD_LIBRARY_PATH=/opt/rh/rh-python35/root/usr/lib64 /opt/rh/rh-python35/root/usr/bin/python3.5 --version
Finally, for shorthand, append the following alias in your ~/.bashrc
alias python351='LD_LIBRARY_PATH=/opt/rh/rh-python35/root/usr/lib64 /opt/rh/rh-python35/root/usr/bin/python3.5'
For verification, reload the .bashrc by source ~/.bashrc and execute python351 --version.
Well, there you go, now whenever you login again, you have got python351 to welcome you.
This is not just limited to python3.5, but can be helpful in case of other scl installed softwares.
I am trying to follow this tutorial, in order to install the Nix package manager in my home directory instead of /nix.
I am doing the PRoot installation (see 2. in tutorial). At the end, the
tutorial proposes to be smart in Building native packages section, to be
able to run packages without PRoot:
To run packages natively (without PRoot) they have to be build from source because all paths to the nix store are hard-coded. It is simple, really:
mkdir $HOME/nix
nix-channel --update
env NIX_STORE_DIR=$HOME/nix nix-env -i nix
And now your Nix store gets built up using the new paths. The built binaries can be run directly from there.
I did that, but I don't see how it frees me from PRoot. If I don't do the /nix mounting point with PRoot, nothing works (no nix-env executable,
I can't install new packages).
Should this NIX_STORE_DIR environment variable be put in my .bashrc ?
It seems I always need to run PRoot because ~/.nix-profile points to
a /nix/... directory:
.nix-profile -> /nix/var/nix/profiles/default
There are more steps in the tutorial (5., 6.) - should I follow them ? It seems they apply only in case of using the manual installation (step 4.),
although it is not explicit.
Any help would be appreciated :)
For anyone stumbling on this old question: there is no currently supported way to install Nix without root. The above wiki was moved to https://nixos.wiki/wiki/Nix_Installation_Guide . It may well be out of date. PRoot could work, but even then, rebuilding the whole store at a different path is not a good idea, not the least because the binary caches won't help and you'll need to build everything.
I suggest trying Nix in a virtual machine or cloud server.
Future people from Google, it's still unsupported but does work. Script here that installs a couple dependencies, builds a temporary Nix, and uses that to install a proper version in your directory of choice.
I'm using a Windows 7 x64 machine with R-3.1.0. I installed the Rserve package through Rstudio.
The start of Rserve is successful with the following code in Rstudio:
library(Rserve)
Rserve()
I got the following output:
Starting Rserve...
"C:\R\R-31~1.0\library\Rserve\libs\x64\Rserve.exe"
My problem is that I couldn't locate the configuration file. Apparently it can't be "/etc/Rserv.conf".
I did come across a webpage saying that the config file is Rserv.cfg in the working directory (unless changed at compile-time). But which working directory? I have checked the working directory of the current R project as well as the Rserve library directory, but it was not there...Could someone help me with this please? Thank you.
Rserve does not automatically come with a config file, you must make one. Best steps for doing so:
Navigate to the file where you just installed Rserve.exe (C:\R\R-31~1.0\library\Rserve\libs\x64\R, based on the message you copied here)
Find Rserve.exe, Reserve_d.exe, and Rserve.dll there. Copy these files.
Navigate to where R.dll is on your computer. This is probably C:\Program Files\R\R-3.1.3\bin\x64, but may be different depending on where you installed R to.
Copy the 3 files mentioned above to this location.
Create a text file here named "Rserv.cfg" with the arguments you are looking for, such as port 6312 or library(mvoutlier). Yes, I know that this is different from the documentation, but if you start Rserve_d.exe you will see that this is the file it is looking for. I have not had success naming it anything else.
You can start Rserve by specifying the location of the config file. In R instead of just Rserve() try the following:
Rserve(args="--RS-conf C:\\folder\\Rserv.cfg")
If path is more complicated you need to massage it a little bit:
Rserve(args="--RS-conf C:\\PROGRA~1\\R\\R-215~1.2\\library\\Rserve\\Rserv.cfg")
Look in the $RHOME/bin directory
If you can't find it here is a different way to approach it:
Download Rserve at [http://rforge.net/snapshot/Rserve_.tar.gz], and save it in your desired directory
Run R CMD INSTALL Rserve_.tar.gz
This allows you to leave Rserve where you want it.
After looking at the Rserve source code and making some test I found that on Windows platform Rserve try to load the configuration file from the current working directory. Also pay attention because on Windows the file name is RServ.cfg and not Rserv.conf as documented.
The current working directory depends of the process, for example using RStudio by default it is your Documents and Settings folder:
C:\Users\[username]\Documents
but can be changed in the "Global Options" of the IDE
So you can create an "RServ.cfg" text file in that directory with your needed options and starting RServe in the usual way in RStudio
Rserve()
will load your configuration.