I have two boxes:
- CentOS 7.2.x.x vagrant box
and
- Debian/Ubuntu 14.04 trusty vagrant box
On both, I installed Ansible (using their preferred package manager method) and ansible/ansible-playbook commands are working perfectly on both boxes.
On CentOS box, installed Ansible version is:
$ ansible --version
ansible 2.1.2.0
config file = /etc/ansible/ansible.cfg
configured module search path = Default w/o overrides
On Ubuntu box, installed Ansible version is:
ansible 2.2.0.0
On both Ubuntu and CentOS vagrant boxes, When I'm running the following command, it works! i.e. it's spitting out a lot of JSON formatted output hash/values., great:
[vagrant#ip-10-11-12-13 ~/aks/workspace] $ ansible all -m setup -i "`hostname`," --connection=local
Now, as I'm specifically looking for 'facter_someVar' variables (which can give me some meaningful information about the local box), so I tried to grep --> "facter_" word from the output of the previous command.
[vagrant#ip-10-11-12-13 ~/aks/workspace] $ ansible all -m setup -i "`hostname`," --connection=local | grep "facter_"
[vagrant#ip-10-11-12-13 ~/aks/workspace] $
I found that on Ubuntu box, it's showing me a lot of facter_xxxx matching variables (around 71+), but on CentOS box, I'm NOT getting ANY facter_ variable in the output?
I recall, in past, I have used CentOS boxes (vagrant provisioned) and they all showed facter_ variables.
I know there are similar 'ansible_someVar' variables but I'm curious about why facter_xxxxx variables are not showing up here.
OK, I was missing facter package on my other box. The following solved the issue (you may need to get the respective EPEL repo).
sudo yum install facter
Facter is small program that gathers system information such as hardware details, network settings, virtualisation type and kernel/OS information. Seems like Facter was created for Puppet to gather system information (but is also available as a standalone command) so it was not installed for free on the particular vagrant CentOS image I used.
Related
The situation in short
I can't launch an executable (binary or a script) in a WSL2 distro if it wasn't created inside this distro
I can launch scripts and binaries that were created inside the distro shell (not using /mnt/c or /mnt/d in any way)
But I can't launch anything that was created outside and copied inside from Windows (using /mnt/c or /mnt/d)
I can see the copied files in the file system, can "cat" them, can look them up with "which", but I cannot launch them by entering the path into the command line
The questions I have in regards to all this
How come that the shell can't see the files while utils you run from the shell can?
How do I make the shell see files that were copied from outside?
If I can't make the shell launch the files, then how do I launch them?
The Situation in detail
I have Windows 10 with WSL2 and two distros
Ubuntu-20.04
Alpine
In Ubuntu I have a "Hello, World!" project written in C
It compiles in Ubuntu and then and runs in Ubuntu just fine
But, when I copy it from Ubuntu to Windows
cp hello /mnt/d/
and then go to Alpine and copy it inside from Windows
cp /mnt/d/hello .
I then have trouble launching it inside Alpine
Here is the output of file hello command in Ubuntu with some extra formatting (just in case)
$ file hello
hello:
ELF 64-bit LSB shared object,
x86-64,
version 1 (SYSV),
dynamically linked,
interpreter /lib64/ld-linux-x86-64.so.2,
BuildID[sha1]=021352ab7bf244e340c3c42ce34225b74baa6618,
for GNU/Linux 3.2.0,
not stripped
Here's what I have in Alpine
$ cp /mnt/d/hello .
$ ls -l
-rwxr-xr-x 1 pavel pavel 16760 Apr 19 19:07 hello
$ ./hello
-ash: ./hello: not found
Now same with a script copied from Windows
Copy the script inside Alpine from Windows
$ cp /mnt/d/hello.sh .
Checking the contents
$ cat hello.sh
#!/bin/ash
echo Hello!
Setting the execute permission just in case
$ chmod agu+x hello.sh
Trying to run it
$ ./hello.sh
-ash: ./hello.sh: not found
But, I can launch the hello.sh by explicitly calling the ash tool and passing the script path as the argument
$ ash ./hello.sh
Hello!
At the same time, a script created inside Alpine runs just by entering it's path to the command line
$ cat << EOF > hello-local.sh
> #!/bin/ash
> echo Local hello!
> EOF
$ chmod agu+x hello-local.sh
$ ./hello-local.sh
Local hello!
Also, I couldn't make a file that would run from one that wouldn't either by copying it with cp
cp hello.sh hello2.sh
or by copying it with cat
cat hello.sh > hello3.sh
cmod agu+x hello3.sh
Why do I need to copy things from outside
It all started when I wanted to explore how Docker for Windows uses Linux namespaces to separate containers
The distro that Docker for Windows uses is called docker-desktop
The docker-desktop distro neither has utilities that I need for my experiments, nor a package manager to get those utilities
So I tried to copy them from outside
But now Docker for Windows studies is not the only concern
I want to understand this magic that is happening just as bad
To be fair, there really are three separate questions here, but not necessarily the questions you listed in your post:
Secondary question -- Why does your script that you copied to Alpine fail?
As #MarkPlotnick covered in the comments (and you confirmed), it was due to the script having DOS/Windows line endings (CRLF). In general, try to avoid creating or editing Linux text files using Windows tools unless you are sure that they are using Linux line-endings.
Secondary question -- Why does your C program fail when you compile on Ubuntu and copy the binary to Alpine?
Also as #MarkPlotnick mentioned in the comments, this is because Ubuntu uses glibc as the standard library implementation by default, but Alpine uses musl. See a number of questions here for more information. The first one in the list sorted by "relevance" is actually a pretty good one to start with.
Main question -- How to explore the docker-desktop distro
Really, your main goal seems to be how to gain access to certain tools inside the docker-desktop distro in order to learn more about it.
I was going to say, "don't" (with more explanation), but the reality is that I think it's a potentially good learning experience. I've done it, to some degree, so who am I to say it's "too dangerous" or recommend against it? ;-)
I will give fair warning, though -- The docker-desktop distro isn't intended to be run by users. Docker Desktop "injects" links and sockets into your other WSL2 distros (which you can enable/disable per-distro in Docker Desktop) so that its tools, processes, etc., are available to all your WSL2 (and PowerShell/CMD) instances.
I'd personally try to avoid making any changes to the docker-desktop distro itself. They'll likely be overwritten anyway by Docker Desktop when it extracts a new rootfs.
However, we can still gain access to the tools we need by accessing them from another distribution, but without copying them into docker-desktop.
First, a note -- As I think you have probably already figured out,docker-desktop is also musl-basesd. So you'll want to use tools from another musl-based distro like Alpine.
This can be easily accomplished by running the following line once in your Alpine instance (as root):
echo "/ /mnt/wsl/instances/Alpine none defaults,bind,X-mount.mkdir 0 0" >> /etc/fstab
That will add a mount to the Alpine instance into the tmpfs /mnt/wsl mount. You can see my Super User answer here for more details on that.
Once you wsl --terminate Alpine and restart it, you'll have access to the Alpine files from any other WSL2 distribution.
As a useful (for your intent) example, install the util-linux package in Alpine to get access to the lsns command.
Then, in the docker-desktop distro (which I assume you already know to access with wsl -u root -d docker-desktop, but I'll include that command here for other future readers), to list the namespaces:
/mnt/host/wsl/instances/Alpine/usr/bin/lsns
The docker-desktop instance automounts at a slightly different directory than default (see cat /etc/wsl.conf), so you need to adjust the path to /mnt/host/wsl instead of /mnt/wsl.
But with that in place, you can run all (most?) of your Alpine binaries directly in docker-desktop without having to modify it directly. If you have a script in your home directory that you want to run in docker-desktop, for instance:
/mnt/host/wsl/instances/Alpine/home/users/<yourusername>/hello.sh
Note that if you have a binary that requires a dynamically-linked library on Alpine, I'm assuming you'll need to adjust your LD_LIBRARY_PATH accordingly, although I haven't tested. For instance:
LD_LIBRARY_PATH=/mnt/host/wsl/instances/Alpine/usr/lib /mnt/host/wsl/intances/Alpine/usr/bin/<whatever>
For a project I am currently trying to install Mavlink onto a Linux Ubuntu (v20.04.4) using Oracle Virtualbox (v6.1) using python (v3.8) on a machine named test with the user named test. Using the given instructions provided by Install Mavlink, it states to set pythonpath as PYTHONPATH=path_to_root_of_cloned_mavlink_repository. But no matter what I try ranging from ='/home/test/mavlink/pymavlink' to =home/test/mavlink, there has been no indication that it is properly working as no feedback is given after the command and modules are still not being found by the terminal. So my question is if I am using the right command for my versions of programs or if I am even doing the file path right by linux standards. The file path given after downloading the github mavlink repository is "Cloning into '/home/test/mavlink/pymavlink'..."
I've just installed vagrant now I would like to make for example vagrant up global. In the docs I read this:
Sometimes you may want to vagrant up your Homestead machine from anywhere on your filesystem. You can do this on Mac / Linux systems by adding a Bash function to your Bash profile. On Windows, you may accomplish this by adding a "batch" file to your PATH. These scripts will allow you to run any Vagrant command from anywhere on your system and will automatically point that command to your Homestead installation:
Mac / Linux
function homestead() {
( cd ~/Homestead && vagrant $* )
}
But when I add the code above to my ~/.bash_profile:
And restart the terminal vagrant up is not working globally. I have no experience with the ~/.bash_profile file.
I would appreciate it if someone could put me in the right direction
This bash function allows you to type things like: homestead up and it will change directories to Homestead and pass the vagrant command in front of any other vagrant command. homestead up means cd homestead, and vagrant up. Typing vagrant up doesn't invoke the function and vagrant isn't in your path.
What you're looking for is simply adding vagrant to your path. You may do this by adding the executable path of vagrant.
export PATH=$PATH:/usr/local/vagrant:
So, you're bash profile would read:
export PATH=$PATH:/usr/local/bin/:~/composer/vendor/bin:
Note: I'm guessing your vagrant is installed in /usr/local/bin; it might be installed elsewhere, in which case put the proper path in lieu of /usr/local/bin.
While there is no shortage of information on how to set a text editor for the Subversion Command Line Interface to use (see here, here, and here for example), I can't figure out where my local system is getting the text editor information from.
On my system, when I perform an svn commit, it opens vim for a commit message. Since this is what I want, I never really thought about it. This has always just worked. However, recently a co-worker was trying to commit, and it failed with an error saying the editor was not set. I never went out of my way to set an editor, so I am very confused about this.
I am running Ubuntu 12.04 and I have compiled and installed the Subversion CLI client version 1.8.10 from source code. Previous to that, I was using whatever Ubuntu's Canonical system installed with apt-get install subversion.
The Using External Editors section of the Subversion Book states the following possibilities for setting the text editor:
--editor-cmd command-line option
SVN_EDITOR environment variable
editor-cmd runtime configuration option
VISUAL environment variable
EDITOR environment variable
Possibly, a fallback value built into the Subversion libraries (not present in the official builds)
I have investigated these places and have not found how the default text editor is set on my computer:
Not using --editor-cmd option when committing
SVN_EDITOR environment variable not set
editor-cmd is not set in either my ~/.subversion/config, nor in /etc/subversion/config. Both of these files exist, but the line is commented out.
VISUAL environment variable not set
EDITOR environment variable not set
I'm downloading the official repository, so there should be no fallback.
There must be another place where the default can be set. Does anybody know?
Edit: There was a suggestion that Subversion might be calling /usr/bin/editor, and this is not set up on my co-worker's machine. I discovered that /usr/bin/editor is set up the same on both my system and my co-worker's system.
When you download the source directly (and build it - assuming you have the build dependencies met) you specify (or you can omit it) the default fallback editor. Normally source builds are done with something like this on Ubuntu (assume I have extracted/downloaded the subversion 1.8.10 source from here):
./configure
make
sudo make install
Notice the ./configure command above doesn't specify any options. The defaults will install to the prefix /usr/local . Prior to issuing those commands (on Ubuntu 12.04) I ran sudo apt-get build-dep subversion . I then did the commands above to build and install. I made sure that options 1-5 (In the OPs question) were not satisfied and then tried to commit a change to a repository. I got this as a response:
svn: E205007: Commit failed (details follow):
svn: E205007: Could not use external editor to fetch log message; consider setting the $SVN_EDITOR environment variable or using the --message (-m) or --file (-F) options
svn: E205007: None of the environment variables SVN_EDITOR, VISUAL or EDITOR are set, and no 'editor-cmd' run-time configuration option was found
Since I didn't remove the official Ubuntu subversion I had to run mine as /usr/local/bin/svn to make sure I was using the one I built. I could have used sudo apt-get remove subversion to remove the official one as well just to make sure.
Now if one runs these commands to rebuild the source:
make clean
./configure --with-editor=/usr/bin/editor
make
sudo make install
One should find that if options 1 to 5 are not satisfied and this version of subversion is run it should default to running whatever /usr/bin/editor points to. On Ubuntu that will depend on what alternative is being used.
So when Ubuntu does an official build where does their fallback editor come from? I went to the 12.04 source repository for subversion at this link . On the right hand side I downloaded the diff file subversion_1.6.17dfsg-3ubuntu3.4.diff.gz . I opened up the diff file Ubuntu uses and scrolling down you can find they use this set of ./configure options (flags):
confflags := \
--prefix=/usr \
--libdir=$(libdir) \
--mandir=\$${prefix}/share/man \
--with-apr=/usr \
--with-apr-util=/usr \
--with-neon=/usr \
--with-serf=/usr \
--with-berkeley-db=:::db \
--with-sasl=/usr \
--with-editor=/usr/bin/editor \
--with-ruby-sitedir=/usr/lib/ruby \
--with-swig=/usr \
--with-kwallet \
--with-gnome-keyring
The bold entry shows that they use /usr/bin/editor as their fallback.
I have built subversion 1.8.10 from source on Ubuntu 12.04 and got the expected behavior. This suggests one of these possibilities:
On one of the systems the options 1 through 5 is actually met.
One version of subversion was built with the --with-editor configure flag (either directly or indirectly). The fallback would point to whatever the --with-editor configure flag was set to.
On one of the systems the wrong version of subversion is being run. One possibility is that the official subversion on Ubuntu is in fact being used. If that is the case it was built to use /usr/bin/editor as a fallback.
On one of your systems you have an alias (or equivalent) for svn that specifies an editor. Aliases would be specified in a startup script like ~/.bashrc, ~/.bash_profile, /etc/bash.bashrc for example.
I think the normal way to specify this on Linux and other Unix-like systems, is to set the VISUAL environment variable (for GUI editors) or the EDITOR variable (for editors running in a terminal).
Try this:
update-alternatives --display editor
Run strings on your svn binary to see if it mentions Vim or any related env vars inside.
Also committing under strace -f may reveal something.
Set this in your .bashrc file.
Don't forget to "source .bashrc" or reopen terminal.
export SVN_EDITOR='vim'
I am working on AWS services. I have an ec2 ( centos ) instance. I need to configure SQL*Plus client on this centos machine.
The server with whom I want to connect is at some remote area. The server version is oracle-se(11.2.0.2)
How can I get the client installed on the CentOS machine?
Go to Oracle Linux x86-64 instant clients download page
Download the matching client
oracle-instantclient11.2-basic-11.2.0.2.0.x86_64.rpm
oracle-instantclient11.2-sqlplus-11.2.0.2.0.x86_64.rpm
Install
rpm -ivh oracle-instantclient11.2-basic-11.2.0.2.0.x86_64.rpm
rpm -ivh oracle-instantclient11.2-sqlplus-11.2.0.2.0.x86_64.rpm
Set environment variables in your ~/.bash_profile
ORACLE_HOME=/usr/lib/oracle/11.2/client64
PATH=$ORACLE_HOME/bin:$PATH
LD_LIBRARY_PATH=$ORACLE_HOME/lib
export ORACLE_HOME
export LD_LIBRARY_PATH
export PATH
Reload your .bash_profile by simply typing source ~/.bash_profile (suggested by jbass) or Log-out user and log-in again.
Now you're ready to use SQL*Plus and connect your server. Type in :
sqlplus "username/pass#(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.2.1)(PORT=1521))(CONNECT_DATA=(SID=YOURSID)))"
The solution by #ChamaraKeragala is good, but it is unnecessary to logout/login. Instead type:
source ~/.bash_profile
For everyone still getting the following error:
sqlplus command not found
The original post refers to a set of environment variables, the most important of which is ORACLE_HOME. This is the parent directory where the oracle binaries get installed.
Depending on what version of oracle you downloaded you'll have to change the ORACLE_HOME accordingly. For example, the original question's ORACLE_HOME was set to:
ORACLE_HOME=/usr/lib/oracle/11.2/client64
My version of Oracle happens to be 12.1, so my ORACLE_HOME is set to:
ORACLE_HOME=/usr/lib/oracle/12.1/client64
If you are unsure of the version that you downloaded, you can:
cd /usr/lib/oracle after the installation and find the version.
Look at the RPM file oracle-instantclient12.1, where the bolded bits would refer to the version number.
There's a good blog post[1] on $subject. setup oracle client in ubuntu with minimum effort. Following are the main steps on how to step up the client.
In my case, I was installing rpm files using alien package.
Install alien and related packages
sudo apt-get install alien
Install oracle client packages using alien.
sudo alien -i oracle-instantclient11.2-basic-11.2.0.3.0-1.x86_64.rpm
sudo alien -i oracle-instantclient11.2-sqlplus-11.2.0.3.0-1.x86_64.rpm
In my opinion these two steps are the easiest way to install oracle client rpm's on your ubuntu system. (I'm not going to mention about export oracle specific variables as it's already clearly explained in above answers)
Hope it helps someone.
[1] http://pumuduruhunage.blogspot.com/2016/04/setup-oracle-sql-plus-client-on-aws.html
For any one who is using proxy, you'd need to add an extra line to the bash profile. At least this is what made it work for me. I'm using cntlm.
export no_proxy=
Install via zip (tried with 12_2)
First of all there is no need to set ORACLE_HOME.
Simply download the .zip files from here starting with the first one Basic: followed by SQL*Plus: and any additional zips you may need.
Extract them all under /opt/oracle
You will then have a directory: /opt/oracle/instantclient_x_y
On ubuntu I had to do also:
sudo apt install libaio1
To run:
# This can be also done by adding only the path below in: /etc/ld.so.conf.d/oracle-instantclient.conf
export LD_LIBRARY_PATH=/opt/oracle/instantclient_x_y:$LD_LIBRARY_PATH
# This can be added in ~/.profile or ~/.bashrc
export ORACLE_HOME=/opt/oracle/instantclient_x_y
/opt/oracle/instantclient_x_y/sqlplus user/pass#hostname:1521/sidorservicename
At the bottom of the the above link page there are more details.