I have some problems trying to test "needs-restarting -r ; echo $?" inside a RedHat distribution. The command works for cases where a reboot is not required, but I have not been able to voluntarily generate the need to reboot in the operating system, which has made it impossible for me to know if the response to the command works. That is to say the output in 1 of the needs-restarting. Do you know of any way to generate the need to reboot in a controlled manner in RedHat?
You can find which packages require a system reboot after the update to Redhat KB. If you can downgrade one of these packages, you can generate reboot required state. But this is not recommended in production systems. glibc and kernel downgrades can cause problems. You can try it at new installed Rhel server after "yum update".
Related
>wsl -l
Windows Subsystem for Linux Distributions:
Ubuntu-18.04 (Default)
Ubuntu
I made the mistake of setting up everything in the Ubuntu-18.04 version, which is locked to that specific version and doesn't allow dist upgrades (Please prove me wrong). This includes shell customizations, symlinks etc.
I would however like to upgrade Ubuntu every once in a while. What I do not want to do is manually find all the configuration files and copy them to the new distribution.
The Ubuntu distribution is the one from the Windows store; fresh clean with no modifications.
How do I get my data from the old distribution into the fresh Ubuntu store distribution? Or is there a way to upgrade the locked Ubuntu-18.04 distribution (also from the Windows store)?
I know of wsl --export and wsl --import, but as far as I can tell these keep the distribution (with in this case the lack of upgrades) and just place a copy of that distribution into another folder. Which does not solve the dist upgrade problem.
I ended up using the free, legacy version of Aptik (I couldn't get the GTK version to launch). Even though it's no longer maintained, it's still working perfectly well, and only took me a single command to export everything and another single command to import everything again.
I need to install Concourse(CI/CD) on my Local windows machine
Below process I followed :
Install Bosh on local system.
It was successfully install and while executing command at command prompt
then it show version all "bosh" -- "version 3.0.1-712bfd7-2018-03-13T23:26:43Z".
Try Download the concourse-lite deployment manifest file but it fails it shows below error.
Follow the below link to install Concourse :
https://concoursetutorial.com/ --- section For Windows:
I don't reccomend doing this at all because you'll be swimming so far out of the main stream that you'll find tons of issues and no one is going to care enough to want to fix them.
Even if you didn't find any issues, resources require a linux worker for anything to work so your going to need linux anyways.
I recommend running your db, web and linux worker on linux and then running windows workers as needed.
I'm a RHEL newbie. I'm used to a non-Linux Unix, which has a fundamentally different way of dealing with packages.
I want to install ipython for a user on a vanilla RHEL7 system with yum as the package manager.
"yum install python" was fairly straightforward, but given that I'm new to the OS and I don't completely understand what ipython is, I am stumped as to how to proceed.
"yum install ipython" obviously doesn't work and every possible solution seems to require the installation of something else that I don't know how to install in a reasonable manner.
I am trying to keep things as generic as possible so it will be obvious how to update/remove software in the future, so anything that can be done with yum, would be probably preferable.
Installation instructions refer to pip, which I don't have. I possibly need setuptools to run pip, but I can't figure out the appropriate way to get that either. Maybe I can get one or either by installation the EPEL bundle of packages, but I can't find those for RHEL7, at least not in a way that doesn't seem like a "download and install this random file, trust us" method, which seems irresponsible.
Another option is anaconda. Again, there doesn't seem to be a yum-related way to install this, and anaconda itself is only a means to an end to download ipython, so that'd be two levels of abstraction away from the goal.
Additionally, do I even want "ipython" these days, or do I want "jupyter"?
All I care about is that the user should be able to type in "ipython" at the prompt and get the thing he is expecting.
Also, the python installed by yum is 2.7.5-48.el7, which does not seem to be current. I don't care about using the current version unless that prevents me from successfully installing ipython in some other manner, but I thought it might be relevant.
Any suggestions for how to install this thing is the most easily maintainable way? Do I not want the yum version of python?
Thanks for your patience.
Install python-pip from EPEL repository first ( https://fedoraproject.org/wiki/EPEL - it's compatible with all Red Hat entrprise Linux distros - be it CentOS, RHEL, Oracl, ScientificLinux or whatever), (or if you don't trust EPEL repo providers you can use get-pip.py ( https://bootstrap.pypa.io/get-pip.py ) script, but then you have to trust its providers instead) then install via
pip install ipython
I use a Raspberry Pi 1 model B with Raspbian, but when I try to do cabal update, the process gets stuck when it is "Updating the index cache file" and I have to force it to stop. I'm trying to install the latest version of pandoc here, but I cannot use cabal install pandoc either because of the same problem.
I tried to leave it running all night long, but when I returned there was a "kill process" line showing up.
Thanks in advance, and sorry for my poor english :)
If cabal update performance is particularly slow, it may be that you are using an old cabal version prior to the merge of an important patch.
The description explains:
This patch improves cabal update performance by 10x(!) on my system.
Due to this issue, cabal update was using an extreme amount of CPU,
while it should be I/O-bound. The reverse was taking 79s, now it
takes 0.01s.
In maximum rpm under the section on the %pre install script, it mentions that it's rare to use the %pre script. In fact, it further states that (at that time anyway) none of the 400+ RedHat packages used the %pre script.
I would think the %pre script would be the ideal location to stop the existing service before installing files over top of the currently installed version.
Is my thinking wrong? How is it that RedHat got away with never using %pre during upgrade for this purpose in any of their service packages?
Yes %pre is much more commonly used than when "Maximum RPM" was written in 1997. That doesn't change the fact that %pre should be used "rarely".
The reason is that %pre prevents installation (and may cause an entire
transaction to fail if there are needed install time dependencies).
Stopping a service in %pre and restarting in %post opens a larger window
where the service is not running than simply restarting a service in %post
The already running service typically reads its configuration files
only on startup (and so rpm can replace files while daemon is running).
And running executables have a reference count on the file system and so
continue to run even if the file that was executed was removed/replaced
by a newer package.
Well, I went and did the research I should have done before asking this question. I downloaded several service packages from RedHat 7.1 and ran:
rpm -qp --scripts <package-name>.rpm
I found out 1) that it's no longer true that %pre is not used. Even among the few that I checked a couple of them used %pre, and 2) it appears that most services just allow rpm to overwrite their data files and binaries during upgrade, and then use the upgrade portion of the %postun (post uninstall) script to restart (or try-restart) the service.
I would have thought this rather unsafe, as while you're writing over data files (especially) during upgrade, the old running service might get confused. It seems to me ultimately it's safer to stop the service during upgrade on %pre and start it again on upgrade during %postun... but that's just me.