I have taken over a Yocto project, and inside a .bb recipe file, I see the following lines to install new directories in the image:
do_install() {
install -m 0755 -d ${DEPLOY_DIR_IMAGE}/app
install -m 0755 -d ${DEPLOY_DIR_IMAGE}/app/apiary
install -m 0755 -d ${DEPLOY_DIR_IMAGE}/app/lib
install -m 0755 -d ${DEPLOY_DIR_IMAGE}/app/config
install -m 0755 -d ${DEPLOY_DIR_IMAGE}/app/scripts
install -m 0755 -d ${DEPLOY_DIR_IMAGE}/app/keys
This works but I am confused. From my reading about Yocto and doing do_install, I thought that the -m option is only for installing files and not directories.
What is the effect of doing install -m 0755 -d , both the -m and -d options with the install command?
Also, why is there no ${D} variable like in the majority of other directory installations which I see?
I normally wouldn't resort to Stack Overflow for a question like this, but there is so much inconsistency that I don't understand , and hard to find an answer.
The task in question is defined as a shell function. The install command used within is a shell command, not anything Yocto- or BitBake-specific, so you should be looking at its docs for enlightenment, not relying on BitBake documentation or examples. In the context of Yocto in particular, however, you should be looking at the documentation for the GNU coreutils version of the install program (as linked above), which is the one you will invariably find on Linux systems.*
From my reading about Yocto and doing do_install, I thought that the -m option is only for installing files and not directories.
I'm not sure what would make you think that, other than just not seeing it applied to directories before.
What is the effect of doing install -m 0755 -d, both the -m and -d options with the install command?
The -m option sets the mode (access-control bits) of the installed object(s). Directories have modes just like regular files do, and the -m option has the same meaning for installing directories as it does for installing regular files.
The -d option specifies that the names specified for installation are to be taken as directories to be created, along with any missing directories in the specified path. As #jww observed in comments, the effect is analogous to that of mkdir -p.
These options are orthogonal. When used together, their effects combine in the natural way: the specified directories are created, with parent directories if needed, and all directories created are assigned the specified mode. Setting the modes explicitly to 0755 is superfluous, however, because that's the default. That may be why you are not used to seeing -m options used for directories.
Also, why is there no ${D} variable like in the majority of other directory installations which I see?
The Yocto specifications for do_install say that it should install files relative to ${D}, whereas the variable DEPLOY_DIR_IMAGE refers to the location for ready-to-install images. It seems like installing to ${DEPLOY_DIR_IMAGE} would be the wrong thing to do, but that doesn't necessarily mean that it wouldn't produce the desired ultimate effect. Or perhaps the recipe was simply written for some older version of BitBake where it made more sense. In any event, sorting out the the details would be a much deeper and more involved analysis than I am prepared to perform for you.
*install is not standardized by POSIX. The GNU version was inspired by BSD's program of the same name, and current versions of that have similar options and behavior, including specifically with respect to the -m and -d options.
Related
I got a class VM which uses ubuntu 18.04 as a base. The terminal is bash and I confirmed from
echo $0
There is a command called elastalert which auto-complete if I just type "elast" and then hit tab. This is pretty normal for any binaries that locates in $PATH.
However, when i do
which elastalert
It returns no info. I searched the file from root directory
$ sudo find -name elastalert 2>null
./backup/elastalert
./elastic_stack/elastalert
However, both path above are directories. I check the $PATH, it does not contain the above path
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
Q: What kind of linux mechanism allows me to auto-complete elastalert, but the elastalert does not exist in $PATH?
Update:
$type elastalert
elastalert is aliased to `docker run -it --rm --net=bridge --network=labs_esnet --name elastalert --hostname elastalert -v /labs:/labs --link elasticsearch hasecuritysolutions/elastalert:v0.1.31 /usr/local/bin/elastalert'
There are some Qs on why sudo is needed. As you can see below, the files are in directories only accessible to root.
$ sudo find -type f -name elastalert 2>/dev/null
[sudo] password for student:
./var/lib/docker/overlay2/c8b9f4ad647fad4090665c6ee6d63af998265ba008756f6dd24563245043d091/diff/usr/local/bin/elastalert
$ sudo file ./var/lib/docker/overlay2/c8b9f4ad647fad4090665c6ee6d63af998265ba008756f6dd24563245043d091/diff/usr/local/bin/elastalert
./var/lib/docker/overlay2/c8b9f4ad647fad4090665c6ee6d63af998265ba008756f6dd24563245043d091/diff/usr/local/bin/elastalert: Python script, ASCII text executable
I can't give you a specific answer but you may find clues in the bash infotext sections 8.6, 8.7 and 8.8.
In section 8.8 it is ilustrated that scripts that aid completion can be installed separatly from programs which would explain why you get a completion without the said program being in your PATH.
How do I install the anaconda / miniconda without prompts on Linux command line?
Is there a way to pass -y kind of option to agree to the T&Cs, suggested installation location etc. by default?
can be achieved by bash miniconda.sh -b (thanks #darthbith)
The command line usage for this can only be seen with -h flag but not --help, so I missed it.
To install the anaconda to another place, use the -p option:
bash anaconda.sh -b -p /some/path
AFAIK pyenv let you install anaconda/miniconda
(after successful instalation)
pyenv install --list
pyenv install miniconda3-4.3.30
For a quick installation of miniconda silently I use a wrapper
script script that can be executed from the terminal without
even downloading the script. It takes the installation destination path
as an argument (in this case ~/miniconda) and does some validation too.
curl -s https://gist.githubusercontent.com/mherkazandjian/cce01cf3e15c0b41c1c4321245a99096/raw/03c86dae9a212446cf5b095643854f029b39c921/miniconda_installer.sh | bash -s -- ~/miniconda
Silent installation can be done like this, but it doesn't update the PATH variable so you can't run it after the installation with a short command like conda:
cd /tmp/
curl -LO https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh
bash Miniconda3-latest-Linux-x86_64.sh -b -u
Here -b means batch/silent mode, and -u means update the existing installation of Miniconda at that path, rather than failing.
You need to run additional commands to initialize PATH and other shell init scripts, e.g. for Bash:
source ~/miniconda3/bin/activate
conda init bash
I'm trying to install vim-now-haskell on NixOS 17.09.
The installation fails with the exception
*** Installer requires 'curl-config'. Please install and try again.
*** Aborting...
Unfortunately Search NixOS packages doesn't list any package for curl-config. It also isn't in installed curl-7.56.1.
I can hardly believe NixOS doesn't provide curl-config. Therefore I'm looking here for help to find it.
It's in the curl.dev output.
$ ls $(nix-build --no-out-link '<nixpkgs>' -A curl.dev)/bin
curl-config
The reason for this is to keep the closure size of anything the uses curl small. Normally Nixpkgs' stdenv.mkDerivation takes care of those details when processing the buildInputs attribute, but if you're not using Nixpkgs to build something you may have to do a bit more manual work.
Another way to get the curl-config command is nix-shell -p curl, which launches a shell that has the command in its environment.
[user#feb:~]$ nix-shell -p curl
[nix-shell:~]$ curl-config --version
libcurl 7.65.3
[nix-shell:~]$ exit
[user#feb:~]$
NixPkgs also has a curlFull package which has more features enabled, as can be seen by the number of packages in the closure of the runtime library output:
$ nix-store -q --requisites $(nix-build --no-out-link '<nixpkgs>' -A curl.out) | wc -l
6
$ nix-store -q --requisites $(nix-build --no-out-link '<nixpkgs>' -A curlFull.out) | wc -l
29
So for a more capable build of curl, use curlFull.dev.
I'm trying to install and be able to run rabbitmqadmin on a linux machine. Following the instructions described here do not help.
After downloading the file linked, it prompts to copy the file (which looks like a python script) into /usr/local/bin.
Trying to run it by simply invoking rabbitmqadmin results in rabbitmqadmin: command not found. There seems to be no information anywhere about how to get this to work and assumes that all the steps listed on the site should work for all. It seems odd that simply copying a python script to the bin folder should allow it to become a recognised command without having to invoke the python interpreter every time.
Any help is appreciated.
I spent several hours to figure out this, use rabbitmqadmin on linux environment, Finally below steps solve my issue.
On my ubuntu server, python3 was installed, I checked it using below command,
python3 -V
Step 1: download the python script to your linux server
wget https://raw.githubusercontent.com/rabbitmq/rabbitmq-management/v3.7.8/bin/rabbitmqadmin
Step2: change the permission
chmod 777 rabbitmqadmin
Step3: change the header of the script as below(first line)
#!/usr/bin/env python3
Thant's all, Now you can run below commands,
To list down queues,
./rabbitmqadmin -f tsv -q list queues
To Delete ques,
./rabbitmqadmin delete queue name=name_of_queue
To add binding between exchange and queue
./rabbitmqadmin declare binding source="exchangename" destination_type="queue" destination="queuename" routing_key="routingkey"
RabbitMQ decided to omit one vital piece of information.
Make the script executable with chmod +x otherwise it will fail to work.
I want to post my commands for installing rabbitmqadmin, it is combination of other answers, but with a little improvements for using best practice:
sudo rabbitmq-plugins enable rabbitmq_management
wget 'https://raw.githubusercontent.com/rabbitmq/rabbitmq-management/v3.7.15/bin/rabbitmqadmin'
chmod +x rabbitmqadmin
sed -i 's|#!/usr/bin/env python|#!/usr/bin/env python3|' rabbitmqadmin
mv rabbitmqadmin .local/bin/
rabbitmqadmin -q list queues
I suppose that you already create .local/bin/ dir and add it to PATH (on Ubuntu bash add this dir to PATH if it exists).
After install Rabbbitmq on Ubuntu/Debian, you can activate the Rabbitmq Admin Portal using the next command:
rabbitmq-plugins enable rabbitmq_management
Then you can access to the portal from http://localhost:15672. Use the user/password "guest".
Below the steps to install rabbimqadmin:
cd /usr/local/bin/
wget http://127.0.0.1:15672/cli/rabbitmqadmin
chmod 777 rabbitmqadmin
For more details check the official documentation Obtaining rabbitmqadmin
I have a spec file which is similar to:
BuildRoot: /tmp/build_%{name}-%{version}-%{release}
%prep
...
...
%install
# Directories
install -m 755 -d %{buildroot}/usr/app/mypackage/config
install -m 755 -d %{buildroot}/usr/app/mypackage/src
....
# Bash script
install -m 755 script/script1.sh %{buildroot}/usr/app/mypackage/config/script1.sh
install -m 755 script/script2.sh %{buildroot}/usr/app/mypackage/config/script2.sh
install -m 755 script/myapp-log %{buildroot}/etc/logrotate.d/myapp-log
When I run the rpmbuild I get the error:
install: cannot create regular file `/tmp/build_my_app-1.0-2/etc/logrotate.d/myapp-log'
I can get around this by manually creating the /etc/ and then /etc/logrotate.d directories in the /tmp/build_my_app-1.0-2/ directory.
When I re-reun the rpmbuild it will work.
I guess this is because I am not creating this directory in my install section but as its not directly related to my application I don't want to put that in.
My guess is that there is some clever tag I can use to fix this so that the build will work without any manual intervention.
My Question:
Could someone please suggest a way for me to achieve this (assuming its possible) or whether I need to write a script around the rpmbuild to set this up first.
You are missing the step to create the installation directories in your %install section. Remember that since you can build in "different" roots, you cannot expect certain directories (like ${buildroot}/etc) to be present.
Try adding
mkdir -p ${buildroot}/etc/logrotate.d
just before the install command that copies the file into ${buildroot}/etc/logrotate.d.