I want to perform the FreeBSD upgrade between releases (from 9.1 to 9.2). Generally the sequence of actions is the following:
freebsd-update fetch
freebsd-update upgrade -r 9.2-RELEASE
freebsd-update install
Is it possible to do this without answering to the questions during the second step (like how to merge the config files), i.e. to perform the installation in "silent mode"?
It is important for me because I need to migrate between releases on 50 hosts. For that reason the number of questions should be the minimum.
Is there maybe an opportunity to create pre-configuration file which will contain the answers to the future questions? Appreciate any input.
Thanks!
There is a yes utility, which simply prints y's into stdout. You can pipe it's output to freebsd-update to achieve unattended install:
yes | freebsd-update upgrade -r 9.2-RELEASE
As for freebsd-update fetch, it's used to download patches for current release, so if you are upgrading, you need only upgrade and install.
Related
I have installed a version (0.12.24) of Terraform which is later than the required version (0.12.17) specified in our configuration. How can I downgrade to that earlier version? My system is Linux Ubuntu 18.04.
As long as you are in linux, do the following in the terminal:
rm -r $(which terraform)
Install the previous version:
wget https://releases.hashicorp.com/terraform/1.3.4/terraform_1.3.4_linux_amd64.zip
unzip terraform_1.3.4_linux_amd64.zip
mv terraform /usr/local/bin/terraform
terraform --version
That's it, my friend.
EDIT: I've assumed people now use v1.3.5 so the previous version is v1.3.4.
You could also checkout Terraform Switcher - this will allow you to switch between different versions easily.
First, download latest package information using:
sudo apt-get update
The simplest way to downgrade is to use apt-get to install the required version - this will automatically perform a downgrade:
Show a list of available versions - sudo apt list -a terraform
terraform/xenial 0.13.5 amd64
terraform/xenial 0.13.4-2 amd64
... etc
or use sudo apt policy terraform to list available versions
Install the desired version:
sudo apt-get install terraform=0.14.5
Or, for a 'clean' approach, remove the existing version before installing the desired version:
sudo apt remove terraform
There are other valid answers here. This may be useful if you have a situation, like I do, where you need multiple Terraform versions during a migration from an old version to a new version.
I use tfenv for that:
https://github.com/tfutils/tfenv
It provides a modified terraform script that does a lookup of the correct terraform executable based on a default or based on the closest .terraform-version file in the directory or parent directories. This allows us to use a version of Terraform 0.12 for our migrated stuff and keep Terraform 0.11 for our legacy stuff.
You shouldn't be installing terraform in ubuntu any more. Generally speaking, the industry has moved on to docker now. You can install docker like this:
sudo apt install -y curl
curl -LSs get.docker.com | sh
sudo groupadd docker
sudo usermod -aG docker $USER
Once installed you can run terraform like this:
docker run -v $PWD:/work -w /work -v ~/.aws:/root/.aws hashicorp/terraform:0.12.17 init
Assuming that your .aws directory contains your aws credentials. If not, you can leave that mount binding (-v ~/.aws:/root/.aws) out of the command and it'll work with whatever scheme you choose to use. You can change the version of terraform you are using with ease, without installing anything.
There are significant benefits in this approach over the accepted answer. First is the ease of versioning. If you have installed terraform using a package manager you can either uninstall it and install the version you need, or you can play around with Linux alternatives (if your distro supports them, or you are using Linux, or a package manager of some sort -- you could be using Windows and have downloaded and run an installer). Of course, this might be a one-off thing, in which case you do it once and you're ok forever, but in my experience, that isn't often the case as most teams are required to update versions due to security controls, and those teams that aren't required to regularly update software probably should be.
If this isn't a one-off thing, or you'd not like to play around too much with versioning then you could just download the binary, as one comment on this post points out. It's pretty easy to come up with a scheme of directories for each version, or just delete the one you're using and replace it completely. This may suit your use-case pretty well. Go to the appropriate website (I've forgotten which one -- Hashicorp or the GitHub repo's releases page, you can always search for it, though that takes time too -- which is my point) and find the right version and download it.
Or, you can just type docker run hashicorp/terraform:0.12.17 and the right version will be automagically pulled for you from a preconfigured online trusted repo.
So, installing new versions is easier, and of course, docker will run the checksum for you, and will also have scanned the image for vulnerabilities and reported the results back to the developers. Of course, you can do all of this yourself, because as the comment on this answer states, it's just a statically compiled binary, so no hassle just install it and go.
Only it still isn't that easy. Another benefit would be the ease in which you could incorporate the containerised version into docker-compose configurations, or run it in K8S. Again, you may not need this capability, but given that the industry is moving that way, you can learn to do it using the standardised tools now and apply that knowledge everywhere, or you can learn a different technique to install every single tool you use now (get some from GitHub releases and copy the binary, others you should use the package manager, others you should download, unzip, and install, still others should be installed from the vendor website using an installer, etc. etc. etc.). Or, you can just learn how to do it with docker and apply the same trick to everything. The vast of modern tools and software are now packaged in this 'standard' manner. That's the point of containers really -- standardisation. A single approach more-or-less fits everything.
So, you get a standardised approach that fits most modern software, extra security, and easier versioning, and this all works almost exactly the same way no matter which operating system you're running on (almost -- it does cover Linux, windows, osx, raspbian, etc.).
There are other benefits around security other than those specifically mentioned here, that apply in an enterprise environment, but I don't have time to go into a lot of detail here, but if you were interested you could look at things like Aqua and Prisma Cloud Compute. And of course you also have the possibility of extending the base hashicorp/terraform container and adding in your favourite defaults.
Personally, I have no choice in work but to run windows (without wsl), but I am allowed to run docker, so I have a 'swiss army knife' container with aliases to run other containers through the shared docker socket. This means that I get as close to a real Linux environment as possible while running windows. I dispose of my work container regularly, and wouldn't want to rebuild it whenever I change the version of a tool that I'm using, so I use an alias against the latest version of those tools, and new versions are automatically pulled into my workspace. If that breaks when I'm doing, then I can specify a version in the alias and continue working until I'm ready to upgrade. If I need to downgrade a tool when I'm working on somebody else's code I just change the alias again and everything works with the old version. It seems to me that this workflow is the easiest I've ever used, and I've been doing this for 35 years.
I think that docker and this approach to engineering is simpler, cleaner, and more secure than any that has come before it. I strongly recommend that everyone try it.
I have accidently ran "pkg_delete -a" on FreeBSD 9.1 .
Is there anyway to restore this operation or revert backwards?
And if not, is there some way to copy the pkg installed on another server? (there are basically 4 servers that are alike they all contain the same packages, this operation only performed on one of them).
You could try bpkg script to generate binary packages for all installed programs. See documentation for -b/-B options.
If I run easy_install -U distribute it starts to upgrade using
/usr/local/lib/python2.6/dist-packages/distribute-0.6.36-py2.6.egg but I need it to be in /usr/lib/python2.6/dist-packages
Any suggestion is much appreciated!
You can use --prefix=/usr to achieve this.
Apart from that it is usually not a good idea to modify the contents of /usr, which are normally maintained by the package management tools of your distribution. With python you can easily upgrade a package locally in your home directory by using --user. This will not confuse the package management of your linux distribution but is specific to a certain user.
RPM is taking care of installing older version and also same version scenario.
If I do update instead of installing new version when old is existing then it updates the package so no problem here.
But When I try to install a new version when an older version exists RPM installs the new version separately thus two versions will exist.
I would like to stop the new version installation when an older exists in my spec file by checking in %pre section. How can I know that rpm -ivh is called or rpm -Uvh is called in my spec file?
if [ "$1" = "1" ]; then
echo Perform tasks to prepare for the initial installation
elif [ "$1" = "2" ]; then
echo You already have old version Please use -U to upgrade.
fi
"$1" = "2" true for both new installation when old is present and for upgrade.
Please let me know how to solve this.
From what I can see, you can't. Find some other way. For example trying to use -i when both already-existing and to-be-installed packages have conflicting files usually stops the installation.
RPM will never install two versions of the same rpm packages that only differ in versions/releases (unless you have some old/buggy version). Now I will assume this is what you wanted:
I have rpm package that should do something a bit different after installation and after upgrade. For example install database on first install, but update it otherwise.
That would mean one of a few things:
You are trying to upgrade automatically something that should be updated by the administrator and/or the program itself. Files generated by the program should not be touched by packages. Ever
You should mark those files as %config in %files section and leave administrator to merge xxx.rpmnew files with the files edited by user
In other words rpms should only touch things it created itself, knows what they contain and can compare it with the database/other source or reliable information. This doesn't seem to be your case
The correct answer is:
yum _____ --nogpgchech
have a nice day!
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
My development server (CentOS 5) is running Subversion 1.4.2, and I wish to upgrade it to 1.5. I have read in various blogs and documents scattered around the web that this may be done by using RPMForge. I have followed the instructions found on CentOS Wiki, including installing yum-priorities and setting my priorities as indicated (1 and 2 for core repo sources, and 20 for RPMForge).
However, when I attempt to run:
$ yum info subversion
the version number given to me is still 1.4.2, with a status of Installed. My other option at this point is compiling from source, but I would like to find a package-managed solution for ease of future upgrades.
Any thoughts?
What you are trying to do is to replace a "core" package (one which is
contained in the CentOS repository) with a newer package from a "3rd
party" repository (RPMForge), which is what the priorities plugin is
designed to prevent.
The RPMForge repository contains both additional packages not found in
CentOS, as well as newer versions of core packages. Unfortunately, yum
is pretty stupid and will always update a package to the latest version
it can find in any repository. So running "yum update" with RPMforge
enabled will update half of your system with the latest (bleeding edge,
possibly unstable and less well supported) packages from RPMForge.
Therefore, the recommended way to use repos like RPMForge is to use them
only together with a yum plugin like "priorites", which prevents
packages from "high" priority repos to overwrite those from "low"
priority repos (the name of the "priority" parameter is very
misleading). This way you can savely install additional packages (that
are not in core) from RPMForge, which is what most people want.
Now to your original question ...
If you want to replace a core package, things get a little tricky.
Basically, you have two options:
Uninstall the priority plugin, and disable the RPMForge repository by
default (set enabled = 0 in /etc/yum.repos.d/rpmforge.repo). You can
then selectively enable it on the command line:
yum --enablerepo=rpmforge install subversion
will install the latest subversion and dependencies from RPMForge.
The problem with this approach is that if there is an update to the
subversion package in RPMForge, you will not see it when the repo is
disabled. To keep subversion up to date, you have to remember to run
yum --enablerepo=rpmforge update subversion
from time to time.
The second possibility is to use the priorites plugin, but manually
"mask" the core subversion package (add exclude=subversion to the
[base] and [update] sections in /etc/yum.repos.d/CentOS-Base.repo).
Now yum will behave as if there is no package named "subversion" in
the core repository and happily install the latest version from
RPMForge. Plus, you will always get the latest subversion updates
when running yum update.
1.- if you are using yum-priorities disable this in the file /etc/yum/pluginconf.d/priorities.conf
2.- check the version of subversion
$ rpm -qa|grep subversion
subversion-1.4.2-4.el5_3.1
subversion-1.4.2-4.el5_3.1
3.- search the last version of the subversion from rpmforge repository
$ yum --enablerepo=rpmforge check-update subversion
subversion.x86_64 1.6.6-0.1.el5.rf rpmforge
4.- now proced to upgrade subversion with rpmforge repository
$ yum shell
>erase mod_dav_svn-1.4.2-4.el5_3.1
>erase subversion-1.4.2-4.el5_3.1
>install mod_dav_svn-1.6.6-0.1.el5.rf
>install subversion-1.6.6-0.1.el5.rf.x86_64
>run
that's all it works for me im running centos 5.4
Thanks Matt - we also have the only distro of SVN 1.7 on SVN.
You may also want to try uberSVN.
If you install RPMForge's repos, you should then be able to get a newer package - this isn't working for you?
You should see rpmforge.list in /etc/apt/sources.list.d with a line like:
repomd http://apt.sw.be redhat/el$(VERSION)/en/$(ARCH)/dag
I just tested on a clean CentOS 5 install, and yum check-update shows
subversion.i386 1.5.2-0.1.el5.rf rpmforge
subversion-perl.i386 1.5.2-0.1.el5.rf rpmforge
So check your sources list and run check-update again.
Edit: Whoops, lost part of my answer. Added it back above.
I'm not overly concerned about the other outdated packages at the moment, but as you can see there is no Subversion update available.
Nor any packages from rpmforge. It's your priority settings. Try disabling yum-priorities (change enabled=1 to enabled=0 in /etc/yum/pluginconf.d/priorities.conf) - then it should work.
So I guess the next question is why the priority is screwing it up.... I'm not sure on this, though.
Edit: See 8jean's answer for more about priorities.
its up to v 1.4.6 in Dag's repository.
You can try the one from Fedora's repo or have a bit of patience for the main repositories to upgrade it.
Making it from source is easy, read the INSTALL file when you download the source package, bear in mind CentOS may have moved where the files get installed. (Use "rpm -ql subversion" to see where the old files were installed to).
When v1.5.0 gets released to the repository, you can delete your built version and install using yum as before.
RPMForge is already in /etc/yum.repos.d/ as rpmforge.repo, and the contents are:
# Name: RPMforge RPM Repository for Red Hat Enterprise 5 - dag
# URL: http://rpmforge.net/
[rpmforge]
name = Red Hat Enterprise $releasever - RPMforge.net - dag
#baseurl = http://apt.sw.be/redhat/el5/en/$basearch/dag
mirrorlist = http://apt.sw.be/redhat/el5/en/mirrors-rpmforge
#mirrorlist = file:///etc/yum.repos.d/mirrors-rpmforge
enabled = 1
protect = 0
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rpmforge-dag
gpgcheck = 1
priority=20
I have that exact line in in /etc/apt/sources.list.d/rpmforge.list .
When I run check-update, I get:
Loading "priorities" plugin
Loading "fastestmirror" plugin
Loading mirror speeds from cached hostfile
* epel: mirror.unl.edu
* rpmforge: fr2.rpmfind.net
* base: mirrors.portafixe.com
* updates: mirrors.portafixe.com
* addons: mirrors.portafixe.com
* extras: mirrors.portafixe.com
2202 packages excluded due to repository priority protections
bzip2.i386 1.0.3-4.el5_2 updates
bzip2-devel.i386 1.0.3-4.el5_2 updates
bzip2-libs.i386 1.0.3-4.el5_2 updates
libxml2.i386 2.6.26-2.1.2.6 updates
libxml2-devel.i386 2.6.26-2.1.2.6 updates
libxml2-python.i386 2.6.26-2.1.2.6 updates
perl.i386 4:5.8.8-15.el5_2.1 updates
sos.noarch 1.7-9.2.el5_2.2 updates
tzdata.noarch 2008e-1.el5 updates
I'm not overly concerned about the other outdated packages at the moment, but as you can see there is no Subversion update available.
All you need to do is get this script. worked perfectly for me on CentOS 5.3
http://wandisco.com/subversion/os/downloads
No, i don't work there or have any affiliation what-so-ever ... just found it and figured I would let you guys knows.
Good luck.