Guest: Virtual Box (Linux Mint with 2 network adapters)
When I try to create Vercita's db like this:
echo "NETWORKING=yes" >> /etc/sysconfig/network
export SHORT_HOSTNAME=$(hostname -s)
expect install_image/vertica.expect
I get error:
Mapping hostnames in --hosts (-s) to addresses...
hplaptop resolved to multiple (2) addresses: (IPv4...) 10.0.2.15, 192.11.12.102 (IPv6...) <none>
Error: Unable to resolve 'hplaptop'
Installation FAILED with errors.
Try:
echo "NETWORKING=yes" >> /etc/sysconfig/network
export SHORT_HOSTNAME=10.0.2.15 # I assume this is the internal IP add
expect install_image/vertica.expect
If one hostname resolves to two IP addresses, you'd have to expect that behaviour. And IP addresses in a Vertica cluster config are less complicated to work with than DNS names or host names ...
Related
I am following this page on how to test ssh connection.
When i enter this first line:
$ ssh -T git#hostname
I get an error:
ssh: could not resolve hostname
hostname: Temporary failure in name resolution
Make sure you can ping hostname, meaning your DNS does resolve hostname into an IP address.
If not, then SSH would fold back to ~/.ssh/config, looking for a Host hostname entry which would indicate what 'hostname' actually means.
Of course, replace 'hostname' by the actual remote host name you want to reach with this SSH session.
After that, it depends on your OS (Windows, Linux, ...), both for the source and the target.
I'm trying to determine the mapping behaviour of a NAT using two STUN servers. I need two stun servers with the same IP but different port.
I was wondering if it's possible to set up two coturn stun servers on the same host.
Assuming your host as two or more valid IP addresses. In the examples below, let's assume the host has two public IP addresses: 1.2.3.4 and 1.2.3.5.
stuntman has this option to bind to multiple IP addresses if offered by the same host.
stunserver --mode full --primaryinterface 1.2.3.4 --altinterface 1.2.3.5
And if running in a NAT'd environment with port forwarding (such as AWS), you can specify the IP mappings such that the CHANGED_ADDRESS or (OTHER_ADDRESS) will be correct when it responds to STUN binding requests. Example:
stunserver --mode full --primaryinterface 10.0.0.4 --altinterface 10.0.0.5 --primaryadvertised 1.2.3.4 --altadvertised 1.2.3.5
Where 10.0.0.4 and 10.0.0.5 are the private LAN ip addresses of the host.
coturn appears to have the same option with the -L and -X options
turnserver -L 1.2.3.4 -L 1.2.3.5
With the -X option used to specify the advertised address in a NAT scenario.
I used kvm as a hypervisor and I have some virtual machines on it.
I can to ssh to the host (hypervisor server) and I want to get all virtual machines' IP addresses.
Is there any way to get the virtual machines' IP addresses by virt tool or other commands like this?
Try this commands from the console of the host machine:
# virsh list --all
Get the VM names from this list
Now for each VM name do the following:
# virsh domiflist *VMname*
Get the MAC of the VM machine
# arp -e
Find the IP address
Ping the hostname from the KVM host and you can get the IPS address.
I am trying to execute the container named redis which is running right now.But the error Could not connect to Redis at redis:6379: Name or service not known. Any one please hell me to figure out the issue and fix it.
This is because both the containers are not in same network, Add a network property inside service name and make sure its same for both
redis:
networks:
- redis-net
Naming the container doesn't alter your hosts file or DNS, and depending on how you ran the container it may not be accessible via the standard port as Docker does port translation.
Run docker inspect redis and examine the ports output, it will tell you what port it is accessible on as well as the IP. Note, however, that this will only be connectable over that IP from that host. To access it from off of the host you will need to use the port from the above command and the host's IP address. That assumes your local firewall rules allow it, which are beyond the scope of this site.
Try below command
src/redis-cli -h localhost -p 6379
I am trying to execute an MPI program in 2 different PCs. However, when I ran this command in pc1:
mpirun -hosts user#host -n 4 bin/Demo_01.exe
I'm getting this error:
[proxy:0:0#pc2] HYDU_sock_connect (./utils/sock/sock.c:203): unable to connect from "pc2" to "pc1" (Connection refused)
[proxy:0:0#pc2] main (./pm/pmiserv/pmip.c:209): unable to connect to server ubuntu at port 57395 (check for firewalls!)
Although I configured SSH connections as without password and disabled firewalls on each machines, the error is still there. My operating system is Ubuntu 12.04 and mpi is MPICH2.
Is there anyone to help?
the error is caused by the the client not connecting back to server as it doesnt know the ip of the server i.e
..main (./pm/pmiserv/pmip.c:209): unable to connect to server ubuntu at...etc
the fix is to add each of hostname and related ip in the /etc/hosts i.e
172.17.0.2 master
172.17.0.3 node1
172.17.0.4 node2
this should allow for bi-directional communication of the master and the node clients
I had the same error, but the accepted answer did not help me.
For me in the hosts file I had:
localhost:8
CPUX:2
I should of had:
CPUZ:8
CPUX:2
I.e the name of the node instead of localhost. Maybe this might help some one.
Fixed. After I followed these steps, the error disappeared:
Create administrator user accounts in both machines with the same username and password.
Define hostnames by editing the file: /etc/hosts
Make a clean install of ssh in both machines.
Configure ssh for connecting without a password. To do this follow these links:
http://www.thegeekstuff.com/2008/11/3-steps-to-perform-ssh-login-without-password-using-ssh-keygen-ssh-copy-id/ and http://dustymabe.com/2012/08/18/exchanging-ssh-keys-using-ssh-copy-id/
Locate the executable MPI program into the same paths in both machines.
montekristo_07's answer is mostly correct but not minimal; steps #2 and #3 are not strictly necessary.
You do not need to edit all your hosts' /etc/hosts files, and, if your LAN uses DHCP and you have any local DNS service running, you should not edit all your hosts' /etc/hosts files.
Insure that:
only externally-resolvable hostnames are referenced in your mpiexec command line (i.e. not "localhost"), and
the /etc/hosts file on the master (the machine on which you run mpiexec) does not have a line associating the public name of the master with the loopback address (127.0.0.1)
A simple test is to use literal IP addresses in your mpiexec command line. If this fixes your problem, then it's a hostname resolution problem...somewhere.
What is essential is to remember is that what is passed on your mpiexec command line, in particular host names, are going to be sent to and resolved on remote hosts.