不羁月人

RabbitMQ报错Error: unable to connect to node rabbit@xxx: nodedown的解决方式

Wed, 23 Nov 2016 21:43:47 +0800

环境：Win10x64+erlang_otp_19.1x64+RabbitMQ3.6.6

刚开始研究RabbitMQ，就遇到问题：

安装好之后，按照官方安装向导执行rabbitmqctl status命令检查状态时，报如下错误：

Status of node 'rabbit@DESKTOP-RVK1IHE' ...
Error: unable to connect to node 'rabbit@DESKTOP-RVK1IHE': nodedown
DIAGNOSTICS
===========
attempted to contact: ['rabbit@DESKTOP-RVK1IHE']
rabbit@DESKTOP-RVK1IHE:
  * connected to epmd (port 4369) on DESKTOP-RVK1IHE
  * epmd reports node 'rabbit' running on port 25672
  * TCP connection succeeded but Erlang distribution failed
  * Authentication failed (rejected by the remote node), please check the Erlang cookie
current node details:
- node name: 'rabbitmq-cli-22@DESKTOP-RVK1IHE'
- home dir: C:\Users\TNT
- cookie hash: oVa+k73FyoNB9z87SvbEAQ==

根据提示，应该是Erlang的cookie出现问题。谷歌后找到了两种解决方式（还有集群的解决方案，这里无关就不阐述了）：

1、重新安装RabbitMQ的服务

For some reason the service set up by the installer did not configure several registry entries. Running this set them correctly and allowed the service to run.

这是由于某些原因在安装服务时没有正确配置注册项，重新安装服务即可解决：

以管理员身份运行RabbitMQ Command Propmt（开始菜单中）
执行rabbitmq-service remove
执行rabbitmq-service install

然后再测试是否成功。

2、更正Erlang的cookie

Erlang会生成两个cookie文件：C:\Windows\.erlang.cookie 及 C:\用户\你的用户名\.erlang.cookie。检查两个文件内容是否一致，不一致用其中一个替换另一个即可。

我这里用第二种方式解决了问题，正如程序提示是cookie不正确所导致。

目前还不清楚为何会这样，网上查阅的资料很多都是集群才会出现这种情况，可能是bug，有待探究。

参考：http://stackoverflow.com/questions/28258392/rabbitmq-has-nodedown-error

Fedora 17/18 之 JDK7安装和配置

Wed, 23 Jan 2013 21:18:48 +0800

前言

Fedora自带的openjdk很多时候不符合要求，所以JDK的安装和配置是必须的操作，整理一下备忘。 P.S.1.这里以jdk-7u11-linux-x64为例。 P.S.2.经Fedora17/18测试成功。

安装JDK

# 0. 下载JDK：官网

# 1. 切换到root用户su

# 2. 安装JDK

#32位

rpm -Uvh /your/path/jdk-7u11-linux-i586.rpm

#64位

rpm -Uvh /your/path/jdk-7u11-linux-x64.rpm

# 3. 安装java, javac, javaws 和 libjavaplugin.so

## (1) java ##

alternatives --install /usr/bin/java java /usr/java/latest/jre/bin/java 20000

## (2) javac ##

alternatives --install /usr/bin/javac javac /usr/java/latest/bin/javac 20000 
alternatives --install /usr/bin/jar jar /usr/java/latest/bin/jar 20000

## (3) javaws ##

alternatives --install /usr/bin/javaws javaws /usr/java/latest/jre/bin/javaws 20000

## (4-1) Firefox浏览器Java插件32位 ##

alternatives --install /usr/lib/mozilla/plugins/libjavaplugin.so libjavaplugin.so /usr/java/latest/jre/lib/i386/libnpjp2.so 20000

## (4-2) Firefox浏览器Java插件64位 ##

alternatives --install /usr/lib64/mozilla/plugins/libjavaplugin.so libjavaplugin.so.x86_64 /usr/java/latest/jre/lib/amd64/libnpjp2.so 20000

# 4. 检查java, javac, javaws 和 libjavaplugin.so 的版本，看是否安装成功

## (1) java ##

java -version

#输出类似于下面

java version "1.7.0_11" Java(TM) SE Runtime Environment (build 1.7.0_11-b21) Java HotSpot(TM) 64-Bit Server VM (build 23.6-b04, mixed mode)

## (2) javac ##

javac -version

#输出类似于下面

javac 1.7.0_11

## (3) javaws ##

javaws

#输出类似于下面

Java(TM) Web Start 10.11.2.21-fcs

## (4) libjavaplugin.so ##

#重启浏览器，然后 [Ctrl + Shift + A] 打开插件页面，切换到 [Plugins] 标签，查看java plugin是否是正确的版本#

5. 切换java, javac, javaws 和 libjavaplugin.so 的版本

alternatives --config java
alternatives --config javac 
alternatives --config javaws
alternatives --config libjavaplugin.so 
alternatives --config libjavaplugin.so.x86_64

配置JDK环境变量

考虑到JDK经常被使用，所以这里设置为全局环境变量。

# 1. 切换到root用户su

# 2. 添加java.sh到profile.d中，以免直接编辑profile带来隐患

## (1) 新建java.sh ##

vi /etc/profile.d/java.sh

## (2) 添加以下内容 ##

JAVA_HOME=/usr/java/latest/ CLASSPATH=.：$JAVA_HOME/lib/tools.jar：$JAVA_HOME/lib.dt.jar PATH=$JAVA_HOME/bin：$PATH export JAVA_HOME CLASSPATH PATH JAVA_OPTS CATALINA_OPTS

## (3) 更改权限 ##

chmod 755 /etc/profile.d/java.sh

# 3. 执行命令

source /etc/profile
source /etc/profile.d/java.sh

Fedora 17/18 之 SSH基本配置及无密码（密钥验证）登录配置

Wed, 23 Jan 2013 20:52:15 +0800

前言

最近因为毕设需要搭建Hadoop，理所当然的要用到SSH无密码登录了，其实就是用公私钥认证的方式进行登录。不久前曾在Fedora17上测试成功，结果因为一些细节上的问题，昨天在Fedora18的时候配了大半天都没成功，还以为是新版本Fedora的问题=。= 多方查阅资料后，直到凌晨才配置成功…这里就整理一篇综合的SSH配置文章，巩固一下记忆。

P.S.1.本文为单机本地访问，多机远程访问操作类似。

P.S.2.本文在Fedora17和18下测试成功。

SSH基本配置

首先安装openssh-server和openssh-clients，执行如下命令：

sudo yum install openssh-server openssh-clients

然后配置SSH服务器配置文件sshd_config，执行如下命令：

sudo vi /etc/ssh/sshd_config

将下面各行前的注释符#(如果有的话)去掉：

Port 22 Protocol 2 RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys

Port 22为SSH端口
Protocol 2为使用协议2
RSAAuthentication yes为使用RSA验证
PubkeyAuthentication yes为使用公钥验证
AuthorizedKeysFile .ssh/authorized_keys为指定验证公钥文件所在的路径

昨天就是最后三行没去掉注释才导致无法公钥验证，只能用密码登录… 还有一些常用的选项，下面简单介绍一下： PermitRootLogin #是否允许root用户登录，为了安全，一般都设置为no

MaxAuthTries #最大验证尝试次数，默认为6，为防止暴力破解，一般设置更小的值
MaxSessions #最大连接数，就是允许连接的客户端数量，这个视情况而定了
PermitEmptyPasswords #是否允许使用空密码，为了安全一般设置no，不过既然用密钥验证的话，这个意义就不太大了吧

接下来启动SSH，执行如下命令：

sudo systemctl restart sshd.service 或 sudo service sshd restart

服务器配置完毕，到客户端配置。如果只是单机本地访问的话不配置也能正常访问。

修改客户端配置文件ssh_config（注意，是ssh_config而不是sshd_config，前者是客户端配置文件，后者是服务端的配置文件），执行如下命令：

sudo vi /etc/ssh/ssh_config

将下面各行前的注释符#去掉（如果有的话）：

Port 22 Protocol 2,1

这样就可以了。

在SSH访问测试之前，还要对防火墙进行设置，允许SSH端口被访问。这里有两种方法：

方法一.执行如下命令：

sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT

方法二.执行如下命令：

sudo vi /etc/sysconfig/iptables

在文件内追加：

-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT

然后测试SSH访问，执行如下命令（ssh后的是目标主机地址，这里是本地测试所以用localhost）：

ssh localhost

首次连接会提示站点未知，问你是否要继续连接，这里键入yes。接着会提示输入密码，输入用户密码(输入的密码不会显示)后回车，出现类似下面的信息的话即登录成功：

Last login: Wed Jan 23 15:52:55 2013

至此，SSH基本配置完毕。

SSH密钥验证无密码登录配置

上面的配置在每次访问时都要键入密码，很不方便。只要通过使用密钥验证的方式，就可以避免输入密码的繁琐性。至于验证原理这里就不赘述了，自行去充电吧。简单举个例子：A想通过SSH访问B，即A是客户端，B是服务器，那么就需要A生成密钥对，然后将公钥提供给B，在每次登录验证的时候，B会使用A的公钥随机生成一个加密的密码发给A，A用自己的私钥解密后将解密的密码回发给B，B验证通过后A就登录成功了。

所以首先是客户端生成密钥对，键入如下命令：

ssh-keygen -t dsa -P '' -f ~/.ssh/id_dsa上

面的dsa可用rsa替代，两者是不同的加密方式。生成的密钥对将存放在home目录的.ssh隐藏目录下，id_dsa.pub是公钥，id_dsa是私钥。

然后将公钥发给服务器并追加到authorized_keys文件中，执行如下命令：

cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys

由于这里是本地测试，所以authorized_keys文件路径不变，如果是远程访问的话，可以使用scp命令进行公钥传送，scp使用方法清自行查找资料。

最后有一点很重要，就是authorized_keys文件的权限，由于RSA对文件权限十分敏感，所以必须对文件进行权限设置。执行如下命令：

chmod 600 ~/.ssh/authorized_keys

权限可以是600或者644，如果漏了这点的话就无法使用密钥验证了。测试无密码登录，执行如下命令：

ssh localhost

这时就不会提示输入密码，直接登录成功了。以上配置完毕。

结语

配这个SSH真心花了太多时间，但因此也学到了不少东西。在配置的时候主要注意几点：服务端配置文件的配置、防火墙配置、authorized_keys文件权限设置。

一句总结，果真细节决定成败。

下面是一篇对我很有用的文章里的一部分——SSH调试步骤，转过来备忘，感谢原作者。

以下内容转自：忘了

用ssh -v 显示详细的登陆信息查找原因：

$ ssh -v localhost

回车显示了详细的登陆信息如下：

。。。。。。省略
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information Unknown code krb5 195
debug1: Unspecified GSS failure. Minor code may provide more information Unknown code krb5 195
debug1: Unspecified GSS failure. Minor code may provide more information Unknown code krb5 195
debug1: Next authentication method: publickey
debug1: Trying private key: /home/huaxia/.ssh/identity
debug1: Trying private key: /home/huaxia/.ssh/id_rsa
debug1: Offering public key: /home/huaxia/.ssh/id_dsa
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: password huaxia@localhost's password:

同时用root用户登陆查看系统的日志文件：

$tail /var/log/secure -n 20

。。。。。。省略
Jul 13 11:21:05 shnap sshd[3955]: Accepted password for huaxia from 192.168.8.253 port 51837 ssh2
Jul 13 11:21:05 shnap sshd[3955]: pam_unix(sshd:session): session opened for user huaxia by (uid=0)
Jul 13 11:21:47 shnap sshd[4024]: Connection closed by 127.0.0.1
Jul 13 11:25:28 shnap sshd[4150]: Authentication refused: bad ownership or modes for file /home/huaxia/.ssh/authorized_keys Jul 13 11:25:28 shnap sshd[4150]: Authentication refused: bad ownership or modes for file /home/huaxia/.ssh/authorized_keys
Jul 13 11:26:30 shnap sshd[4151]: Connection closed by 127.0.0.1
。。。。。。省略

从上面的日志信息中可知文件/home/huaxia/.ssh/authorized_keys 的权限有问题。查看/home/huaxia/.ssh/ 下文件的详细信息如下：

$ ls -lh ~/.ssh/

总计 16K 
-rw-rw-r-- 1 huaxia huaxia 602 07-13 11:22 authorized_keys 
-rw------- 1 huaxia huaxia 672 07-13 11:22 id_dsa 
-rw-r--r-- 1 huaxia huaxia 602 07-13 11:22 id_dsa.pub 
-rw-r--r-- 1 huaxia huaxia 391 07-13 11:21 known_hosts

修改文件authorized_keys的权限（权限的设置非常重要,因为不安全的设置安全设置,会让你不能使用RSA功能）：

$ chmod 600 ~/.ssh/authorized_keys

再次测试登陆如下：

$ ssh localhost

Last login: Wed Jul 13 14:04:06 2011 from 192.168.8.253

看到这样的信息表示已经成功实现了本机的无密码登陆。

8.认证登陆远程服务器（远程服务器OpenSSH的服务当然要启动）

拷贝本地生产的key到远程服务器端（两种方法）

方法一：

$cat ~/.ssh/id_rsa.pub | ssh 远程用户名@远程服务器ip 'cat - >> ~/.ssh/authorized_keys'

方法二：

在本机上执行：

$ scp ~/.ssh/id_dsa.pub michael@192.168.8.148:/home/michael/

登陆远程服务器michael@192.168.8.148 后执行：

$ cat id_dsa.pub >> ~/.ssh/authorized_keys

本机远程登陆192.168.8.148的测试：

$ssh michael@192.168.8.148

Linux michael-VirtualBox 2.6.35-22-generic #33-Ubuntu SMP Sun Sep 19 20:34:50 UTC 2010 i686 GNU/Linux Ubuntu 10.10 Welcome to Ubuntu! * Documentation: https://help.ubuntu.com/ 216 packages can be updated. 71 updates are security updates. New release 'natty' available. Run 'do-release-upgrade' to upgrade to it.

Last login: Wed Jul 13 14:46:37 2011 from michael-virtualbox michael@michael-VirtualBox:~$

可见已经成功登陆。如果登陆测试不成功，需要修改远程服务器192.168.8.148上的文件authorized_keys的权限（权限的设置非常重要,因为不安全的设置安全设置,会让你不能使用RSA功能）

chmod 600 ~/.ssh/authorized_keys

JAVA解惑之奇数性

Wed, 21 Mar 2012 07:12:46 +0800

有一段时间没写过东西了，由于各种状况。今晚就抽些时间来更新一篇。

如题所示，这次要讨论的是JAVA中关于判断一个数（这里以int为例）是否为奇数的问题。

首先看以下的代码：

boolean isOddBy1(int i) {
return i % 2 == 1;
}

当使用0、1、2……等测试时，结果符合期望。这样看起来以上的代码是没错的。的确，在一定程度上来说这个方法具有正确性，但只局限于非负整数，当使用负奇数测试时，会发现结果不符合期望。例如-3的时候会返回false，即判断结果为不是奇数。稍微有些数学基础的人都明白，负数求余返回的值也是负数。而Java 对取余操作符（%）的定义所产生的后果。该操作符被定义为对于所有的 int 数值 a 和所有的非零 int 数值 b，都满足下面的恒等式：

 (a / b) * b + (a % b) == a

换句话说，如果你用b整除a，将商乘以b，然后加上余数，那么你就得到了最初的值 a 。该恒等式具有正确的含义，但是当与 Java 的截尾整数整除操作符相结合时，它就意味着：当取余操作返回一个非零的结果时，它与左操作数具有相同的正负符号。当i为负奇数时，其余数为-1，因此上面的方法将返回false。

这个问题很容易解决，只需与0作判断即可，见下面的代码：

boolean isOddBy0(int i) {
return i % 2 != 0;
}

然后测试正负整数和零都能返回期望值。这个问题看起来很低级，但也是容易犯的错误之一，所以不得不注意。其实这个问题是出自于《JAVA解惑》，我只是为了加强记忆而操作一遍并以文章的形式发出来。或者你会觉得这有些多余，但脚踏实地也是提高编程能力的关键。

曾经初中的一位老师对我说过，“你像一匹老马，脚踏实地，一步一步向前走”。从今以后我也会继续保持这样的步伐不断迈进。