"%pre – This is where code is run before the install scripts run."
this section does not work for me .
I got a spec file from “http://repo.andrewfarley.com/centos/specs/zabbix.spec” . every thing is ok ,but the rpm package can not create the “zabbix” user .
any reply is appreciated .Thank you .
OS : CentOS 5.7
That spec file is broken. They will delete the user during an upgrade in %postun. %postun should check it's parameter and only delete the users if it is given 0, i.e. "zero packages of this name will be installed when this transaction is complete."
Were you doing an install or an upgrade?
Related
I have access to a Linux server at work where I code in RStudio. Recently, the pull/push buttons have been greyed out in the git pane, and I also haven't updated from basic password authentication which I know GitHub is deprecating soon. However, I can't get it to accept a PAT, and clearly this repository has gotten unlinked from GitHub somehow.
When I run git remote -v from the terminal, I see the correct repository and branches.
When I run gitcreds::gitcreds_set() from R, it shows my correct GH username, and that it has saved a password. It then gives me an option to replace the credentials, but when I put in a new PAT (shown below as XXXXXX), I get an error:
-> What would you like to do?
1: Keep these credentials
2: Replace these credentials
3: See the password / token
Selection: 2
-> Removing current credentials...
? Enter new password or token: XXXXXXXX
Error in new_git_error("git_error", args = args, stdout = out, status = attr(out, :
System git failed: error: unknown option `get-urlmatch'
usage: git config [options]
I tried googling this error but haven't come across anything useful. Thanks in advance for any ideas. I imagine that fixing the git connection will also fix the greyed-out push/pull buttons in RStudio.
The --get-urlmatch option to git config first appeared in Git version 1.8.5. While any modern Linux system will ship with a Git version of at least 2.0, there are a bunch of rather old systems that still come with Git 1.8 or even 1.7 variants.
There might be a way to work around this in RStudio, but your best bet is probably to get a newer Git version installed on the system. Git is generally pretty backwards-compatible although there were a few user-interface-default changes between 1.x and 2.0 (and there's another one coming up, though I doubt anyone will call this 3.0).
I am new to Version control and this is my first attempt. I am also a novice in R. just did an online course. I have installed Git and was trying to add the Version control through Rstudio Global options. The Git executable file path shows "user/bin/git" But when I go to create a Project>version control>Git- I get an error "Git was not detected on the path" I dug deeper and ran cmd in the mac terminal- which git and got the location as "/usr/local/bin/git", I also did a $ git --exec-path and got the location as "/usr/local/Cellar/git/2.30.0/libexec/git-core" I understand the executable path is somewhere else. I understand that I need to change the path but Rstudio is not allowing the changing of the path, and I am unable to edit the path to "/usr/local/Cellar/git/2.30.0/libexec/git-core" from "user/bin/git". I tried manually entering but that doesnt work, I browsed through the file s and sub folders and selected the executable file location , but it still doesnt change. Please help.
Welcome to stackoverflow: You can find a step by step support on the official support site of rstudio. Here you get detailed instructions on how to use version control with RStudio: https://support.rstudio.com/hc/en-us/articles/200532077-Version-Control-with-Git-and-SVN
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.
Running Rstudio-server and a recent version of R. With the recent upgrade possibilities of RStudio, I wanted to upgrade.
From what I've read, I should be able to do it by simply running the
sudo gdebi [package name]
However, this gives me a string of errors.
It gets down to 'Setting up studio-server (0.99.441) ...
useradd: user 'studio-server' already exists
groupadd: group 'rstudio-server' already exists
rstudio-server stop/waiting
rstudio-server start/running, process 9823
#
I have tried started or stopping the server to get it to install, performing an install without these options and can't get it to upgrade. Google and RSeek turned up nothing, so maybe there is something I'm supposed to know but don't.
Thank you.
What I did:
- extract what is in the tar or in the .deb
- rename the folder usr/lib/rstudio (just in case)
- make a new directory /rstudio
- copy all the content of the tar in the new folder
You will need sudo permissions to rename and copy.
What I use is >sudo nautilus
and as allways. Be carefull with what you change with sudo.
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.