How to build Mongodb C driver without sudo - c

I am trying to build the C driver of MongoDB afetr I have build MongoDB and started it.
On github, I have found that I need root privileges to build it (I need to run it with sudo).
Is it possible to do it without sudo ?

The instructions there state
make
sudo make install
So you ARE building as a normal user, but of course, installing it will require root privileges.
On a side note: using DESTDIR will install with a prefix the binaries don't know about. Software installed with DESTDIR is typically not runnable from the place it is installed. If you want to install in a non-standard location, do it at build-time (e.g. if the project uses autotools, pass a --prefix=/home/foo/mytree to ./configure).
DESTDIR is only useful for creating packages. I use my own little package manager implemented in perl for managing installations in the /usr/local tree. It works by setting DESTDIR to /usr/local/pkg/<product_name> with make install and then symlinking everything to its correct location.

I have just now realised that I can change the installation directory while installing using DESTDIR as a destination directory.
In my case it would look like this: make DESTDIR=new_path install

Related

Install Racket package only if not installed

I can install a Racket package with:
raco pkg install <pkg-name>
If the package is not installed, it installs it. If the package is already installed however, it will complain that the package is already installed. While this is fine, is there a better way to check if a package is installed, and only try to install it if its not already installed?
For context, I want this because I have a (non-package) Racket project that relies on certain packages being installed. I could put them in an info.rkt file, but as far as I can tell, these won't get installed unless I try to install the project as a package, which doesn't make sense for this domain.
So, is there anyway to determine if a Racket package is installed? Additionally, can I use this information to only install a package if its not already installed?
Yes, in fact you can. If you are using a shell program or makefile (basically, using the raco pkg tool from the command line), you can pass it the --skip-installed parameter. This will only try to install the package if its not already installed. So you could do something like this in a mace file:
all: # Replace spaces here with tabs, because make...
raco pkg install --skip-installed <important-pkg>
<rest-of-makefile>
Alternatively, if you are looking for an 'in Racket' solution, you can use the installed-pkg-table function to get a hash table containing all of the installed packages. From there, its easy enough to do a hash-has-key? to see if the package is in the table. From there, you can use pkg-install-command to install the package. Your total code will look something like this:
(unless (hash-has-key? (installed-pkg-table) "<important-pkg>")
(pkg-install-command #:deps 'search-auto i))
I should note that there is a slight chance that the package database will change between searching for the key and installing the package. If that is important to you, check out with-pkg-lock

Where does sdkman install packages?

I used sdkman to install groovy which went fine. Where is the installed package now? I need the path for it. I am on Ubuntu 14.04.
I've checked it on my system. It should be located in $HOME/.sdkman/candidates/.
I think the best way would be to use SDKMan's home command:
https://sdkman.io/usage#home
Something like this (taken from the above page):
$ sdk home java 11.0.7.hs-adpt
/home/somedude/.sdkman/candidates/java/11.0.7.hs-adpt
Upon installation, SDKMAN creates an environment variable $SDKMAN_DIR which points to the installation directory.
Usuall it's ~/.sdkman
After you have run source $HOME/.sdkman/bin/sdkman-init.sh.
You can see the sdkman "installation" by running:
declare -f
$HOME on mac is /Users/<users>
Where's SDKMan installed:
echo #SDKMAN_DIR
Where did it just install gradle? (or some other package)
which gradle
SDKMAN stores file in $HOME/.sdkman/candidates/ as Tom mentioned and this answer goes into more detail.
To find where SBT 1.3.13 is installed, type sdk home sbt 1.3.13. It'll return something like /Users/powers/.sdkman/candidates/sbt/1.3.13.
The arguments to the sdk install command align with where the files are stored in $HOME/.sdkman/candidates.
sdk install java 8.0.272.hs-adpt stores files in $HOME/.sdkman/candidates/java/8.0.272.hs-adpt.
sdk install sbt 1.3.13 stores files in $HOME/.sdkman/candidates/sbt/1.3.13.
When you run sdk install, the downloaded binaries get saved in $HOME/.sdkman/archives. For example, $HOME/.sdkman/archives/java-8.0.272.hs-adpt.zip and $HOME/.sdkman/archives/sbt-1.3.13.zip.
Some of the binaries are pretty big and can end up taking a lot of space on your computer. You should periodically delete them with the sdk flush archives command. Once you install the software, you don't need the binaries anymore. See here for more details.

How to apply puppet manifests and modules WITHOUT installing Puppet RPM?

I would like to create an RPM package that applies a Puppet manifest on a server which does not contain Puppet, Facter and Hiera.
Also, and more importantly, I should be able to apply it WITHOUT being obliged to install neither of these tools (Puppet, Facter, Hiera) on the production server.
So basically, the package should run the following command without installing any of the required packages:
puppet apply install.pp --modulepath=./modules --hiera_config=./conf/hiera.yaml
How can I proceed to make such a package ? Is it a good idea to extract the 'binary' files the Puppet/Hiera/Facter RPMs to include them in another one ?
Thanks!
Installing the relevant packages and then removing them would be by far the fastest and safest way to do what you wish. Maybe you can convince your customer that the cost in time for any other solution is not worth the money.
Anyway, if packages are not an option, let's be innovative:
You do not have to install from packages, you can install puppet via ruby gems
In the same way, you can use source tarballs
Those two options might work, but are not innovative enough.
What about installing puppet 'locally' on a disk via the gems or the tarballs, and then mounting this disk via nfs?
While we are here, why not do the same but then mount using sshfs?
still with the idea of a having first a remote install, you could indeed repackage it via fpm (amazing tool, very strongly recommended). You still end up with a package, but a local one which will not require adding a repository, this might alleviate some of your client concerns.
building on this, if the issue is with repositories, not packages, you could download all required packages and install them manually
I guess that the summary of this answer is that the value of doing so is negative compared to using what you distribution provides.

rethinkdb index-rebuild complains python driver is missing

Ran into this error when trying to run rethinkdb rebuild command:
Error when launching 'rethinkdb-index-rebuild': No such file or
directory The rethinkdb-index-rebuild command depends on the RethinkDB
Python driver, which must be installed. If the Python driver is
already installed, make sure that the PATH environment variable
includes the location of the backup scripts, and that the current user
has permission to access and run the scripts.
Yet I have the rethinkdb python module installed and path setup properly:
Requirement already satisfied (use --upgrade to upgrade): rethinkdb in
/Library/Python/2.7/site-packages Cleaning up...
Why doesn't this work?
If the rethinkdb-index-rebuild script is not in your PATH, you might be able to invoke the index-rebuild command as
python -mrethinkdb._index_rebuild
Turns out it was a feature implemented in a newer version of the python module. Solved it by:
sudo pip install --upgrade rethinkdb

how to create a debian package using “equivs-build” which can be “upgraded” if already installed?

I have created a .deb package using equivs-build command and providing necessary control, preinst, postinst, etc. I noticed that version can also be mentioned in control file. Now I want to create a .deb package with updated source code and I want to enable user to upgrade the package if it is already installed (and is of previous version, of course), as I won't be changing conf related files, etc. One way I can think of is to write a shell-script which will first check for installed version, and will take actions accordingly (i.e. if installed, just update the source-code, database-migrations, etc. and if not, install the package using dpkg -i <package-name>). I was wondering if there was a way to achieve using dpkg only (something like dpkg upgrade <package-name>) which will handle installation or up-gradation as required.
That's already how it works.
dpkg -i package_0.123.deb will upgrade if the version of package is less than 0.123, removing the previous version if necessary (there's an option to force a downgrade, too). apt-get install package will install the newest version of package, removing the old one and upgrading to a new one if necessary. apt-get upgrade will upgrade all packages to the newest version.
Basically, just take care to monotonically upgrade the version number each time you publish a new build.
If you didn't specify a version previously, the default will be something simple like 1.0. Just make it bigger than that.

Resources