Host Inspector message while installing CDH 4 - expected hostname and actual hostname - linux

I am trying to install CDH 4 on Ubuntu 10.x. Everything worked fine. But the Host Inspector gave the following message.
host hadoop.ubuntu.com expected to have name hadoop.ubuntu.com, but resolved (InetAddress.getLocalHost().getHostName()) to Ubuntu-64bit.
This is how the entry in the hosts file looks
192.168.56.101 hadoop.ubuntu.com Ubuntu-64-bit
So I have two queries
1. Is the syntax of specifying hostname in the line - 192.168.56.101 hadoop.ubuntu.com Ubuntu-64-bit, incorrect and what is the proper way?
2. If I let CDH 4 run with this message, will any functioning get affected?

The cluster (single node though) started fine without any issues so far. So looks like this host inspector warning did not cause any problems. Also changing the syntax of the line of IP address in the hosts file causes more issues. So I am closing this question for now.

Related

How to set up custom hostnames and ports for servers (eg node.js) running in WSL 2

(I've provided a simple working solution in response)
I recently moved from macOS to WSL 2. I have two node servers running within WSL 2 (Ubuntu distro). Each must be accessible through a custom hostname for development vs production purposes. I've had difficulty accessing the node servers via custom hostnames (ie set in some ../etc/hosts file) especially given WSL 2's dynamic IP that changes per WSL/pc 'boot'. How does one go about setting custom hostnames in WSL 2?
Scenario:
Each node.js app server (again running within WSL 2) must be accessed from the browser with the following urls/custom hostnames:
www.app1.com:3010
www.app2.com:3020
After searching around I have found the following relatively simple process works. I thought I'd share and save some time and headache for those new to WSL 2. Note, although I'm using node as the server stack, this process should more or less be the same for other app/web server stacks.
Note the following SE post is the basis of the solution. It's also worthwhile to examine MSFT's reference on WSL vs WSL 2. Also note, I haven't provided deep rationale on why these steps are required, why we might need custom hostnames, ipv6 options in ../etc/hosts, the meaning of 127.0.0.1, loopback addresses, WSL 2 and distro management, etc. These are subjects beyond the scope of this post.
Simple scenario:
nodeApp1: node application server with custom hostname: 'www.app1.com' on port 3010 (or whatever)
nodeApp2: node application serverwith custom hostname: 'www.app2.com' on port 3020 (or whatever)
Each node.js app server (again running within wsl 2) can be accessed from the browser with the following urls:
www.app1.com:3010
www.app2.com:3020
Two key items:
The correct etc/hosts files to be modified is on the Windows side (not WSL distro) at: C:\Windows\System32\drivers\etc\hosts (yes in Windows folders). This is a 'hot' update so no need for WSL 2 reboot. The content for this scenario is:
127.0.0.1 localhost
127.0.0.1 www.app1.com
127.0.0.1 www.app2.com
255.255.255.255 broadcasthost
::1 localhost www.app1.com www.app2.com
Please add C:\Users\"you"\.wslconfig with the following content (yes in Windows folders):
[wsl2]
localhostForwarding=true
Note: there's a reference to this in WSL 2 Ubuntu distro's /etc/hosts.
Also note, this requires WSL shutdown and reboot. Shutting down your terminal is insufficient. Also total machine boot is not
required. Simply run:
wsl --shutdown (in Powershell) or
wsl.exe --shutdown (within Ubuntu)
Then restart the Windows Terminal app (or any WSL terminal) to access the updated WSL 2 environment. The apps with custom urls/hostnames will now work in the browser permanently and WSL 2's dynamic IP is circumvented.

Cassandra-3.10 on Ubuntu 14.04 malfunctions on machine restart

Here's what I have:
- I installed a cassandra 3.10 version on my Ubuntu 14.04.
- I have it running as a service.
- I've modified cassandra.yaml file to listen to my node
- I have a single node.
Everything was working fine; until I had to restart my machine. I hit the command:sudo service cassandra stop (I tried restarting my machine without stopping cassandra as well), then restarted my machine. When i got back, and tried to access through cqlsh, I get the following error:
Connection error: ('Unable to connect to any servers', {'192.168.2.202': error(111, "Tried connecting to [('192.168.2.202', 9042)]. Last error: Connection refused")})
When I look for nodetool status, instead of a valid Host ID, I see null. I tried nodetool refresh, but no luck.
Can anyone tell me what's wrong?
The issue is now resolved.
I was going through Cassandra's download instructions to check if I had messed something up during my installation.
Then I came across this information: "Even numbered versions are bug fixes and new releases and features, possibly buggy (with existing bugs from new features); odd numbered versions are bug fixes to its immediate predecessor".
Apparently, this is something called the "tick-tock" release.
I believe that was the problem - a bad version. I just checked it out with the now-latest Cassandra version - 3.11 (odd == less buggy), and it's working perfectly. Lesson learned - never deploy the latest Cassandra version in production if the version is even!
References:
https://www.datastax.com/dev/blog/cassandra-2-2-3-0-and-beyond
https://www.pythian.com/blog/cassandra-version-production/

Cygwin Error : tcp_peer_send_blocking: send() to socket

My Cygwin installed on Windows 7 was working properly till I try to install a new package. The package installation failed. Then I keep getting this error every time I want to run my Open MPI program. I can successfully compile the program but cannot run it. I even remove and make a new installation without success.
Thanks for any hints. Below is the sample error message.
[Reloaded-PC:03900] [[3921,1],0] tcp_peer_send_blocking: send() to socket 13 failed: Transport endpoint is not connected (128)
[Reloaded-PC:03900] [[3921,1],0] tcp_peer_send_blocking: send() to socket 13 failed: Transport endpoint is not connected (128)
[Reloaded-PC:04676] [[3921,1],2] tcp_peer_send_blocking: send() to socket 13 failed: Transport endpoint is not connected (128)
[Reloaded-PC:04676] [[3921,1],2] tcp_peer_send_blocking: send() to socket 13 failed: Transport endpoint is not connected (128)
The problem is solved by disabling the unused network adapter in "Control Panel->Network and Internet->Network Connections".
It turned out the unused network adapter tried to get configured by DHCP and an IP address started with "169.254.X.X" was assigned to this adapter when DHCP fails. Somehow openmpi on Cygwin use that invalid IP address for establishing communication between processes.
I figured it out by looking at /tmp/openmpi-sessions-{username}/{PID of orterun}/contact.txt.
I had this same problem on Cygwin with OpenMPI 1.10.4.
Try adding "-report-uri -" to your mpirun command to see what IP address it's trying to use for connection:
mpirun -report-uri - -np 2 a.exe
It should print out a line that looks something like this:
568328192.0;tcp://192.168.10.103,169.254.247.11,0.0.0.0,0.0.0.0,0.0.0.0:55600
If the first IP address after the "tcp://" is not a current valid address for your machine, that's the problem and things are likely to break (even if the correct IP appears later in the list). Apparently ORTE is not smart enough to order the interfaces based on what is actually enabled and online.
If the wrong IP corresponds to an old/disabled interface, uninstall it (if possible) using the windows network connections control panel.
In my case, the first address was a DHCP address for an old hardware adapter I'd removed and thrown away long ago (but apparently not uninstalled in software). Windows normally hides such removed-but-not-uninstalled interfaces in the control panel, but the settings remain in the registry under:
HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\
Search in that registry subkey for the bogus IP address and you are likely to find the problematic interface. I fixed mine by changing the IP address in that registry key to match my current static IP, but uninstalling the interface entirely would probably also work.
I had the same problem with openmpi v 1.8.8 (which is the default version of the package installed by cygwin). Manually going back to version 1.8.6 fixed the issue for me.
I just encountered this problem and in my case I had to disable the "VirtualBox Host-Only Network" adapter (I recently installed virtualbox and have not used openmpi in cygwin after that until today).
1. Open the Cygwin terminal.
mpicc --version
mpirun --version
If not execute, follow the document below and reinstall everything. Document
2. Try turning off Bluetooth and test your program again.
3. Try closing the Wifi and test your program again (you can connect to the wired internete)
4. Open C:\Windows\System32\drivers\etc\hosts
add line
127.0.0.1 localhost cygdrive wpad
and test your program again.
5. If you have a virtual network like VirtualBox or similar, turn off the control panel and test your program again.
6. If possible, uninstall VirtualBox completely. Restart your computer and test your program again.
7. Try turning off the Windows Firewall and test your program again.
The above steps solved both the "tcp_peer_send_blocking: send () to socket 12 failed: transport endpoint is not connected" error and the slowness problem in MPI for Windows 10 - Cygwin.

Could not connect to cassandra with cqlsh

I want to connect to cassandra but got this error:
$ bin/cqlsh
Connection error: ('Unable to connect to any servers', {'192.168.1.200': error(10061, "Tried connecting to [('192.168.1.200', 9042)]. Last error: No connection could be made because the target machine actively refused it")})
Pretty simple.
The machine is actively refusing it because your system does not have cassandra running on it. Follow the following steps to completely get rid of this trouble :
Install Cassandra from DataStax (Datastax-DDC; Cassandra version 3).
Go to ~\installation\path\DataStax-DDC\apache-cassandra\bin.
Open up cmd there. (Use Alt+F+P to open it if you are on windows 8 or later).
type cassandra -f this will generate a lot of stuff on the window and you must get the last line as INFO 11:32:31 Created default superuser role 'cassandra'
Now open another cmd window in the same folder.
Type cqlsh
This should give you a prompt, without any error.
I also discovered that this error doesn't pop up if I use cassadra v2.x found here Archived version of Cassandra. I don't know why :( (If you find out please comment).
So, if the above steps do not work, you can always go back to Cassandra v2.x.
Cheers.
Check if you have started Cassandra server, then provide the host and port as the arguments.
$ bin/cqlsh 127.0.0.1 4092
I run into the same problem. This worked for me.
Go to any directory for example E:\ (doesn't have to be the same disc as the cassandra installation)
Create the following directories
E:\cassandra\storage\commitlogs
E:\cassandra\storage\data
E:\cassandra\storage\savedcaches
Then go to your cassandra installations conf path. In my case.
D:\DataStax-DDC\apache-cassandra\conf
Open cassandra.yaml. Edit the lines containing: data_file_directories, commitlog_directory, saved_caches_directory to look like the code below (change paths accordingly to where you created the folders)
data_file_directories:
- E:\cassandra\storage\data
commitlog_directory: E:\cassandra\storage\commitlog
saved_caches_directory: E:\cassandra\storage\savedcaches
Then open the cmd (I did it as administrator, but didn't check if it is necessary) to your cassandra installations bin path. In my case.
D:\DataStax-DDC\apache-cassandra\bin
run cassandra -f
Lots of stuff will be logged to your screen.
You should now be able to run cqlsh and all other stuff without problems.
Edit: The operating system was windows10 64bit
Edit2: If it stops working after a while check if the service is till running using nodetool status. If it isn't follow this instruction.
I also faced the same problem on a Win32 windows 7 machine.
Check if you have JAVA installed correctly and JAVA_HOME variable set.
Once you have checked the java installation and set JAVA_HOME, uninstall Cassandra and install it again.
Hopefully this would solve the problem. Mine was solved after applying the above two steps.
You need to mention host, user, password for cassandra cqlsh connection. Default cassandra cqlsh user is cassandra and password is cassandra.
$ bin/cqlsh <host> -u cassandra -p cassandra
I also had same problem. I applied many methods given on google and youtube but none of them worked in my case. Finally, I applied the following 3 steps and it worked in my case:-
Create a folder without any space in C or D whichever is your system drive. eg:- C:\cassandra
Install Cassandra in this folder instead of installing in"Program Files".
After installation, it will be like this- C:\cassandra\apache-cassandra-3.11.6
Copy python 2.7 installed in bin folder i.e.,C:\cassandra\apache-cassandra-3.11.6\bin
Now your program is ready for work.
There is no special method to connect cqlsh it simple as below:-
$ bin/cqlsh 127.0.0.1(host IP) 9042 or $ bin/cqlsh 127.0.0.1(host IP) 9160 (if older version of Cassandra)
Don't forget to check port connectivity if you are connecting cqlsh to remote host. Also you can use username/password if you enabled by default it is disabled.

How to change the host name of the ubuntu server running oracle xe

I have a oracle 11g XE instance running under ubuntu server. I tried changing the hostname of the server by modifying the host name in /etc/hostname, /etc/hosts, tnsnames.ora and listener.ora but the oracle-xe instance fails to start after reboot. Any idea which configuration I am missing?
Sometimes Oracle starts with only certain services / functionalities not working properly... If that's the case and your Oracle instance partially failed to start you can get some more information about running listeners by invoking the lsnrctl command line utility and then using the status command.
You can also look for clues in the Oracle log files under <oracle-install>/app/oracle/diag/tnslsnr/<hostname>/listener/alert/log.xml - you should definitely have one for your old hostname and you might have another one created for your new hostname as well.
I had this and solved it just rename your listner.ora and restart, it will change the setting for the new host name
see my explanation Here

Resources