Could anyone tell me how to change yum install default directory? I have been trying to install datastax cassandra after creating the datastax.repo file in yum.repos.d directory but when installing it says no enough space. it is installing in default / file system. can i change to /data or /local/apps directory where there is plenty of space. how can i do this. commands used: yum install dse-full;
many thanks for the help
You don't. Not really.
If the RPM is built as a relocatable RPM (almost none are that I'm aware of). Then, and only then, you can use the --prefix or --relocate arguments to rpm to do some amount of prefix replacement/path translation.
That said that is almost certainly not the case.
If the rpm installs to under a specific prefix (e.g. /opt/cassandra) then you might be able to create a symlink at that location to your other partitions and that might work.
A better option (and one that might be more reliable) would be to use a bind mount at that location to somewhere on your other partition.
That said the real answer here is to give your root partition more space. Which, assuming you used LVM to create your partitions (and you really probably should) is not a complicated task.
I've been stuck on a legacy server with insufficient disk space, and had to use an approach similar to this answer.
You can find out where it wants to install to using rpm commands:
rpm -q -p -l /path/to/rpmfile.rpm |less
If it installs under a common directory such as /usr/local/, you're in luck. I cannot download the RPMs from the vendor, since it requires registration, but from the docs about the .run installer for the same product, the default is /usr/local/dse.
If this is the same for the .rpm installs, then you can just symlink that directory to your large disk:
ln -s /usr/local/dse /local/apps/dse
Hope that helps!
Related
My knowledge on Linux administration is limited and hence wanted to check here about the pros and cons of installing any RHEL/CentOS Linux software using rpm packages over installing through tar/zip files.
Thanks
a non-exhaustive list of pros and contras:
rpm
intelligent dependency managment
conflict checking
allow easy and clean uninstall
allow for upgrades / downgrades
list all files owned by a package
a central database with all packages installed, which files they own, their interdependencies
from source
you choose yourself all compiler flags
you can choose a custom installation path
I have tried to explain the diff, pros and cons,
Tar
Basically tar is old way of dealing with in Linux. We can say its existence when the Linux was created.
Usually the tar consists of Source Code and needs to be compiled in binary format for us to use.
Pros:
Using tar packages you gain more control over the programs that you install.
If you want certain portions that avoided, you could do that on the go. Which give you the upper hand.
Cons:
The main issue comes in the maintainability of the packages installed.
They are hard to manage. Once you install, there was no way to manage the software unless and until its well documented. It also hard to version them and you are left blank on the software version you have. The possible reason for this because of the non-indexing nature of files. The files could be spread across your file system, which makes it difficult to remove or upgrade it.
Hard to automate.
It is also hard to automate because of the complexities in maintaining the packages.
Below I tried explaining how tar file are compiled to get better understanding,
Prepare(setup) environment for building
./configure
This script has lots of options that you should change. Like --prefix or --with-dir=/foo. That means every system has a different configuration. Also ./configure checks for missing libraries that should be installed. Anything wrong here causes not to build your application. That's why distros have packages that are installed on different places, because every distro thinks it's better to install certain libraries and files to certain directories. It is said to run ./configure, but in fact you should change it always.
Building the system
make
This is actually make all by default. And every make has different actions to do. Some do building, some do tests after building, some do checkout from external SCM repositories. Usually you don't have to give any parameters, but again some packages execute them differently.
Install to the system
make install
This installs the package in the place specified with configure. If you want you can specify ./configure to point to your home directory. However, lots of configure options are pointing to /usr or /usr/local. That means then you have to use actually sudo make install because only root can copy files to /usr and /usr/local.
Please go through the below link for more information on the above commands
Why always ./configure; make; make install; as 3 separate steps?
RPM
The RPM Package Manager (RPM) is an open packaging system,
RPM packages pre-compiled binary packages (as well as source packages) for an easy one-click installation experience. RPM by itself does not manage dependency and resolve conflicts. When combined with Yum or PackageKit it will resolve all the dependency for the package.
RPM makes system updates easy. Installing, uninstalling and upgrading RPM packages can be accomplished with short commands. RPM maintains a database of installed packages and their files, so you can invoke powerful queries and verification on your system. During upgrades, RPM handles configuration files carefully, so that you never lose your customisation, that you cannot accomplish with regular .tar files.
RPM feature has the ability to verify packages. If you deleted an important file for some package, you can verify the package. You will notified of changes, if any—at which point you can reinstall the package, if necessary. Any configuration files that you modified are preserved during re installation.
Pros:
Install, reinstall, remove, upgrade and verify packages
Use a database of installed packages to query and verify packages
Use metadata to describe packages, their installation instructions, and so on
Package pristine software sources into source and binary packages
Add packages to Yum repositories
Digitally sign your packages
Querying a package (if the package is on your local file system or after the package is installed)
Validating a package (checking a package has not been tampered with, before or after installation).
Cons
Not as customisable as tar.
eg on usability: We will see how to install package using Tar or rpm:
in Tar:
$ tar xvf package.tar
$ cd package
$ ./configure --prefix=PREFIX
$ make
$ make install
in RPM:
rpm -U package-2.4.x-1.i686.rpm
That simple!!.
It basically depends on the usability and the purpose of your use.
Each of them has its on pros and cons depends on how and for what we use it.
I know it a long explanation,how this will give you clear picture. I know there are more untouched such as architecture and execution. I am not pretty confident to explain those here.
In simple words you can say that rpm are prepackaged binaries. They're just ready to go, it does everything for you. But to install rpm and deb you need to be root to have some write permissions. That leaves some serious security hole in the system. You may be unknowingly installing a Torjan horse. Also if the packages are screwed up they may cause the installation to fail altogether.
I personally recommend using tar as you are in more control. It is old school, I know, that's why a bit difficult but, in my opinion best way to go.
You can further refer to the link:
https://tldp.org/HOWTO/Software-Building-HOWTO-4.html
In my fedora x64 system I accidently did removed the "filesystem" package while I was root , by executing this command :
rpm -e filesystem --nodeps
instead of doing this :
yum update filesystem
and unfortunatly the command executed normally and the "filesystem" package was deleted totally .
now the system is refusing to boot up showing this message :
systemd[1] : Failed to execute /bin/sh , giving up : No such file or directory
Now I can't do anything to fix it so any solutions are welcome, because I don't want to reinstall the system .
I am running an x64 Fedora 18 linux on an intel i3 processor.
I ran into the same beast on Fedora 19, after 3 hours I found a quite straight forward solution, what I did was:
Boot from Fedora-Live USB-stick of the same version installed
Mounted root into a local directory (btrfs): mount -o subvol=/root /dev/sda3 /mnt
Downloaded the filesystem package, telling yum it's working and base-directory are at my mountpoint: yum -c /mnt/etc/yum.conf --installroot=/mnt --downloadonly --downloaddir=/~ install filesystem
Since the package filesystem.x.x.x.rpm was gloriously removed by the rpm -e filesystem --nodeps command already, I installed the downloaded filesystem.rpm - at least I thought so. Turned out I had to force rpm because some other package from Google-Earth was blocking my command:
rpm -Uvh --root=/mnt ~/filesytem.x.x.x.rpm --force
Finally I edited /etc/selinux/config, I turned it off:
SELINUX=disabled
I'd take the drive out, install it in another system mount it as a secondary drive, and fool around with RPM to install the package in the specified path.
Bear in mind you'll need to manually check all your dependencies are installed too, and that you're building the correct version for Fedora 18.
I guess there might be other ways to do this too, but as long as you have another system you can connect the drive to, this might be the least effort.
I'd boot your broken system off a rescue disk on DVD, CD, USB or what have you. My experience was with Knoppix (a few years back), it was regarded as the best. However, if you don't have that, google "fedora rescue" and download that. See if that can read your hard drive, perhaps allowing you to avoid losing files of value that you had on old system, copy out to some removable media. Or, it may actually diagnose your situation and suggest fixing it for you.
Otherwise, I suspect the least-effort path back to a working system will be to install linux from scratch. The "filesystem" is not a separate package, it pretty much is the linux installation. The kernel is still present and booting, but everything else is gone.
I looked for the ISO mounted it extracted the rpm package filesystem-3.2-10.fc19.x86_64.rpm. I then looked for a live cd, boot into and mounted my former working partition and then run
rpm2cpio /root/filesystem-3.2-10.fc19.x86_64.rpm | cpio -idmv
I have a debian package that I built that contains a tar ball of the files, a control file, and a postinst file. Its built using dpkg-deb and it installs properly using dpkg.
The modification I would like to make is to have the installation directory of the files be determined at runtime based on an environment variable that will be set when dpkg -i is run on the deb file. I echo out the environment variable in the postinst script and I can see that its set properly.
My questions:
1) Is it possible to dynamically determine the installation directory at runtime?
2) If its possible how would I go about this? I have read about the rules file and the mypackage.install files but I don't know if either of these would allow me to accomplish this.
I could hack it by copying the files to the target location in the posinst script but I would prefer to do it the right way if possible.
Thanks in advance!
So this is what I found out about this problem over the past couple of weeks.
With prepackaged binaries you can't build a debian package with a destination directory dynamicall determined at runtime. I believe that this might be possible if installing a package that is built from source where you can set the install directory using configure. But in this case since these are embedded Ubuntu machines they don't have make so I didn't pursue such an option. I did work out a non traditional method (hack) for installing that did work. Since debian packages simply contain a tar ball relative to / simply build your package relative to a directory under /tmp. In the postinst script you can then determine where to copy the files from the archive into a permanent location.
I expected that after rebooting and the automatic deletion of the subdirectory under /tmp that dpkg might not know that the file package existed. This wasn't a problem. When I ran 'dpkg -l myapp' it showed as still installed. Updating the package using dpkg/apt-get also worked without a hitch.
What I did find is that if you attempted to remove the package using 'dpkg -r myapp' that dpkg would try and remove /tmp which wasn't good. However /tmp isn't easily removed so it never succeeded. Plus in our situation we never remove packages but instead simply upgrade them.
I eventually had to abandon the universal package due to code differences in the sources resulting in having to recompile per platform but I would have left it this way and it did work.
I tried using --instdir to change the install directory of the package and it does relocate the files but dpkg fails since the dpkg file can't be found relative to the new instdir. Using --instdir is sort of like a chroot. I also tried --admindir and --root in various combinations to see if I could use the dpkg system relative to / but install relocate the files but they didn't work. I guess rpm has a relocate option that works but not Ubuntu.
You can also write a script that runs dpkg-deb with a different environment for 6 times, generating 6 different packages. When you make a modification, you simply have to run your script, and all 6 packages gets generated and you can install them on your machines avoiding postinst hacking!
Why not install to a standard location, and simply use a postinst script to create symbolic links to the desired location? This is much cleaner, and shouldn't break anything in dpk -I.
I have booted my system from a live Ubuntu CD, and I need to fix some package problems. I have mounted my hard drive, and now I want to run apt-get as if I booted normally. ie change the working directory for apt-get so it will work on my hard drive. I have done this before, but I can't remember the syntax. I think it was only some flag, like this:
apt-get --root-directory=/mnt/partition1 install....
But I only get "Command line option...is not understood". Any ideas?
Also this should work:
sudo apt-get -o Dir=/media/partitioni1 update
chroot /mnt/partition1
If your system uses several disk partitions you may have to mount some of them in order to get the package system working (I stopped setting up multiple partitions 10 years ago when hard disks started to get too large for raw physical backup).
This wouldn't work if you don't already have a usable debian system in that location. – akostadinov
If you can't get the package system working when chrooting, perhaps it is too messed up to ever be trusted again - in my experience the effort to bring it back to life rarely pays. If that happens, be happy you can still access your HD, backup your data and perform a clean reinstall.
Some relevant comments from other answer:
apt-get -o RootDir=/tmp/test_apt sets (almost) all paths to be in the different root. btw on a running system, if you copy /etc/apt, /usr/lib/apt, and mkdir -p usr/lib etc var/cache var/lib/dpkg var/lib/apt/lists/partial var/cache/apt/archives/partial and finally touch var/lib/dpkg/status, then apt is going to work in that root. It can even work as a non-root user if you add the option -o Debug::NoLocking=1. The nolock option is necessary because I couldn't find a way to set the lock file inside the different root directory. – akostadinov
Work means using search and downloading packages and such operations. Actually installing is not possible if some essential packages are not already there. debootstrap can help if the goal is actually installing packages in a new root for whatever reason. – akostadinov
Running chroot /mnt/partition1 will start a new shell in which the root of the filesystem is /mnt/partition1. Assuming the apt-get on your hard drive still works correctly, you can proceed from there.
dpkg --root=/mnt/partition1 -i mypackage.deb is an option that doesn't require chroot, but does require you to download the package yourself.
It seems that the RPM logic is quite different from what I know already and I am having some issues understanding the "RPM logic". For my work, I have to create a documentation on "How-to create a RPM package on Red Hat 5".
I'm used to Debian and it's derivatives (Ubuntu, and so on) and thus to Debian packages (aka. .deb files).
From what I read, it seems that ones need to be root to create a RPM package. While I understand why root could be required to install a package, I still don't understand why elevated privileges should be needed just to create one.
If I try to create a RPM package as a user, changing the buildroot it fails on the %installstep because I don't have permission to write files into /usr/bin. Fair enough but... why does it want to copy my files into /usr/bin at this step?! I just want to create the package, not install it!
I'm sure I'm missing something here. Is there anyone who could give me at least a basic understanding of how rpmbuild works and why?
Will this do?
You don't need to be root to build RPM packages. I recommend you to read this two part article to get you started.
The official Maximum RPM book also has a chapter on Having RPM Use a Different Build Area, which allows non-root users to build RPMs.