1
文档编写目的
根据前面的安装文档，我们知道CDH的安装只能使用root或者具有sudo权限的用户进行安装，但大多数企业对于服务器的root用户的管控比较严格，大多数情况下都不能够直接使用或者需要申请比较麻烦。对于这种情况，Cloudera官方提供了一种单用户安装CDH的模式，参考Fayson前面的文章《0517-如何在CDH5中使用单用户模式》。但实际情况是这种方法非常麻烦，官方其实也不建议使用，而且从CDH6开始也已经废弃了这种安装或使用方式。
本文基于一个实际需求，即CDH相关的所有服务都使用非root用户来管理，主要是Cloudera Manager Server和Agent服务（其他Hadoop服务默认都是使用相应自己的用户比如hdfs或者hive用户），我们知道这2个服务默认会被放到操作系统的/etc/rc.d/init.d下，即会开机自启动，而且Server使用cloudera-scm用户启动而Agent使用root用户启动。实现思路是先从操作系统自启动里移除，然后设置相关脚本，文件和日志的权限来实现使用非root用户的手动启动，这样可以实现未来的非root用户来管理Server和Agent服务，而Hadoop相关服务大部分情况下都可以通过Cloudera Manager界面化来管理。以下Fayson进行实操演示。
- 测试环境
1.CDH5.16.1
2.Redhat7.4
3.采用root进行操作
2
修改cloudera-scm-agent服务
2.1
移除agent服务
1.停止Agent服务
代码语言：javascript复制systemctl stop cloudera-scm-agent2.Kill supervisord进程，如果存在
代码语言：javascript复制[root@ip-172-31-13-38 ~]# ps -ef |grep supervisord
root 1470 1 0 12:39 ? 00:00:11 /usr/lib64/cmf/agent/build/env/bin/python /usr/lib64/cmf/agent/build/env/bin/supervisord
root 14521 13742 0 13:09 pts/0 00:00:00 grep --color=auto supervisord
[root@ip-172-31-13-38 ~]# kill 1470
[root@ip-172-31-13-38 ~]#
3.将/etc/rc.d/init.d/cloudera-scm-agent脚本移到/root/agent_bak下：
代码语言：javascript复制[root@ip-172-31-13-38 ~]# mkdir agent_bak
[root@ip-172-31-13-38 ~]# cd /etc/rc.d/init.d/
[root@ip-172-31-13-38 init.d]# mv cloudera-scm-agent /root/agent_bak/
4.重载systemd服务，并确认agent服务已经被移除。
代码语言：javascript复制[root@ip-172-31-13-38 init.d]# systemctl daemon-reload
[root@ip-172-31-13-38 init.d]# systemctl start cloudera-scm-agent
Failed to start cloudera-scm-agent.service: Unit not found.
[root@ip-172-31-13-38 init.d]#
2.2
修改启动脚本
1.修改启动脚本cloudera-scm-agent
我们编辑cloudera-scm-agent脚本，可以看到如上图一行的启动命令，标红部分为当用户启动cloudera-scm-agent时，会su root来执行该脚本，这也是为什么我们看到的cloudera-scm-agent服务的启动用户是root的原因。因为我们现在要演示用其他用户启动该脚本，所以删掉这部分，然后保存。
2.修改文件夹属组，这里我们计划使用cloudera-scm用户来启动agent服务
代码语言：javascript复制chown cloudera-scm:cloudera-scm /var/log/cloudera-scm-agent/*
chown -R cloudera-scm:cloudera-scm /var/run/cloudera-scm-agent
2.3
手动启动agent服务
1.手动启动agent服务
代码语言：javascript复制sudo -u cloudera-scm sh cloudera-scm-agent start
2.查看CM页面可以检测到该agent的心跳
3.但是发现该节点上的CMS和Hadoop相关服务显示异常。
4.重启CMS服务
重启失败
5.重启172.31.13.38节点上的NameNode服务，报错如下
代码语言：javascript复制Error found before invoking supervisord: Non-root agent cannot execute process as user 'hdfs'
3
修改cloudera-scm-server服务
3.1
停止server服务
1.停止cloudera-scm-server服务
代码语言：javascript复制systemctl stop cloudera-scm-server2.将/etc/rc.d/init.d/cloudera-scm-server脚本移到/root/agent_bak下：
代码语言：javascript复制[root@ip-172-31-13-38 ~]# cd /etc/rc.d/init.d
[root@ip-172-31-13-38 init.d]# mv cloudera-scm-server /root/bak
3.重载systemd服务，并确认server服务已经被移除。
代码语言：javascript复制[root@ip-172-31-13-38 init.d]# systemctl daemon-reload
You have new mail in /var/spool/mail/root
[root@ip-172-31-13-38 init.d]# systemctl start cloudera-scm-server
Failed to start cloudera-scm-server.service: Unit not found.
[root@ip-172-31-13-38 init.d]#
4.修改相应目录的权限
代码语言：javascript复制chown cloudera-scm:cloudera-scm /var/log/cloudera-scm-server/*3.2
手动启动server服务
1.使用cloudera-scm用户启动Cloudera Manager Server服务
代码语言：javascript复制[root@ip-172-31-13-38 bak]# sudo -u cloudera-scm sh cloudera-scm-server start
Starting cloudera-scm-server: cloudera-scm-server: line 249: /var/run/cloudera-scm-server.pid: Permission denied
[FAILED]
[root@ip-172-31-13-38 bak]#
启动失败，这里报错是/var/run的权限，这个目录会挂载到/run下，修改这个目录的权限后可以启动成功，但是重启系统之后，该目录的权限又会还原，最终还是失败。
4
总结
1.本文Fayson尝试手动做一些修改后，使用非root用户来启停server和agent服务，都以失败告终。
2.Agent服务可以配置为使用别的用户来启动，本文是使用cloudera-scm，但是带来的问题是该节点上的CMS服务或者Hadoop相关服务无法管理，因为CM管理节点的原理是通过通过向agent发送相关指令，然后通过agent的用户root来sudo到相关的的组件用户来管理相应的服务，比如sudo到hdfs用户来管理HDFS服务，实际还有CM搜集诊断包也需要通过agent调用很多系统命令来进行搜集。本文其实可以通过配置其他用户比如cloudera-scm用户的免密sudo到其他用户来进行尝试，但是没有再这么做的原因是因为agent管理服务或者调用操作系统本身的系统命令太多，逐项配置是非常麻烦的基本不现实，具体可以参考《0517-如何在CDH5中使用单用户模式》。
3.Server服务主要是因为/var/run目录的权限问题，我们可以临时修改该目录的权限来实现。但因为/var/run最终会挂载到OS的内存系统tmpfs中，一旦重启OS，该目录又会还原，又需要手动设置。
4.综上所述，无论是Cloudera Manager Server还是Agent服务都无法配置为其他用户来启停，只能通过root用户来管理。
5.其实这2个服务如果你配置为其他用户来管理，也不是官方支持的方式，所以无论从技术可行性还是能否享受正式支持的角度来说，都不建议去修改Server和Agent的启停用户。
