CAS部署Gradle-Overlay

参考:https://apereo.github.io/cas/development/installation/Maven-Overlay-Installation.html
这是最简单部署CAS的方法了,之后再更新如何从源码编译。。。

下载模板工程
地址:https://github.com/apereo/cas-gradle-overlay-template/tree/4.2

## 编译

bash
./gradlew[.bat] clean build

制作war文件

bash
./gradlew[.bat] clean build explodeWar

把制作完的war放到tomcat下的webapp即可
配置在etc/cas

需要定制化覆盖对应内容即可,结构如下

├── src
│ ├── main
│ │ ├── java
│ │ │ └── edu
│ │ │ └── vt
│ │ │ └── middleware
│ │ │ └── cas
│ │ │ ├── audit
│ │ │ │ ├── CompactSlf4jAuditTrailManager.java
│ │ │ ├── authentication
│ │ │ │ └── principal
│ │ │ │ └── UsernamePasswordCredentialsToPrincipalResolver.java
│ │ │ ├── services
│ │ │ │ └── JsonServiceRegistryDao.java
│ │ │ ├── util
│ │ │ │ └── X509Helper.java
│ │ │ └── web
│ │ │ ├── HelpController.java
│ │ │ ├── flow
│ │ │ │ ├── AbstractForgottenCredentialAction.java
│ │ │ └── util
│ │ │ ├── ProtocolParameterAuthority.java

定制之后重新执行上面的命令即可

Nginx中文配置文档1-新手引导

本文主要翻译一部分常用的Nginx配置文档
环境:
Ubuntu14.04 x64
Nginx1.4.6

参考内容:
官方文档:http://nginx.org/en/docs/
相关概念:http://blog.hylstudio.cn/archives/380

感谢 Mandy Alexander 提供的参考资料:https://www.websiteplanet.com/blog/html-guide-beginners/

nginx的初步使用

安装:配置好apt源后,执行sudo apt-get install nginx即可
启动:sudo service nginx start
重启:sudo service nginx restart
关闭:sudo service nginx stop
查看状态:sudo service nginx status

默认目录

网站根目录:/usr/share/nginx/html
日志目录:/var/log/nginx
配置文件目录:/etc/nginx

配置文件目录中的
├── sites-available
├── sites-enabled
这两个文件夹和apache配置同理,可以配置多个站点。使用软连接生效。

原文:http://nginx.org/en/docs/beginners_guide.html

本引导提供了nginx基本的介绍和描述以,并提供一些可以用来练习的任务。假设nginx已经在读者的机器上装好了,如果还没有安装,请参考安装指导。这个指导描述了如何启动和停止nginx、重新加载配置文件、解释了配置文件的结构、描述了如何设置nginx用来提供静态内容的服务、如何配置nginx作为代理服务器以及如何用nginx连接FastCGI应用程序。

nginx有一个主进程和多个worker进程,主进程的主要任务是读取加载配置和维持worker进程,Worker进程负责处理实际的网络请求。 nginx使用了基于事件的模型和操作系统相关原型来高效在worker进程中分发请求。worker进程的数量定义在配置文件中,可能是固定的数值或自动的根据可用的CPU核心数调整(参见worker_processes)。

nginx和模块的运行方式由配置文件决定。默认情况下,配置文件名为nginx.conf,放在/usr/local/nginx/conf, /etc/nginx, 或/usr/local/etc/nginx

启动、停止、重新加载配置

以非服务形式启动:
想要启动nginx,执行可执行文件即可,一旦nginx启动,它可以通过调用可执行文件和-s参数来控制,语法如下:
nginx -s signal
在signal的位置可以是以下几种:

stop — 快速关闭
quit — 平滑的关闭
reload — 重新加载配置文件
reopen — 重新打开日志文件

例如,想等待worker处理完当前请求再退出可以这样写:
nginx -s quit
这个命令可以用启动nginx的同一个用户执行。
配置文件的更改不会立即生效,直到执行reload命令或重启nginx,命令如下:
nginx -s reload
一旦主进程收到重新加载配置文件的新号,它会检查新的配置文件语法是否正确并且尝试更新配置。如果成功了,主进程会开启新的worker进程并且向旧的worker进程发送关闭信号来重新加载配置文件。否则,主进程会回滚到之前的状态使用旧的配置继续工作。旧的worker进程接收到关闭信号后,停止接收新的连接请求并把当前的请求处理完,然后旧的进程会结束。

信号也可以在Unix工具的帮助下被发送给nginx,例如kill命令。在这种情况下信号会通过提供的PID直接发送给一个进程,这个PID默认被写入到了名为nginx.pid的文件中,默认情况下存在/usr/local/nginx/logs或者/var/run。例如如果主进程的PID是1628,想要发送QUIT信号的话,执行下面的命令:

kill -s QUIT 1628
想要获得所有运行中的nginx进程,可以使用ps命令如下:

ps -ax | grep nginx
想要知道更多的信息,请查看Controlling nginx章节

配置文件的结构

nginx由多个模块组成,这些模块通过配置文件中的指令控制。指令分为简单指令和块指令,一个简单指令由空格分隔的名称和参数组成,结尾是英文的分号(name parameter [parameter2];)。块指令和简单指令结构一样,但是最后不是分号,而是附加了一系列大括号括起来的附加指令。如果一个块指令可以在大括号中包含其他的指令,那么它可以被叫做上下文,例如events, http, server, and location。

指令放在配置文件中上下文之外,event和http指令属于主上下文、server属于http、location属于server。

以#开头的行为注释

提供静态内容服务

一个web服务器重要的任务就是提供文件(比如图片或静态的HTML页面)服务,你将会实现一个例子,web服务器会基于请求,从本地不同的文件夹中提供文件服务。/data/www (这里放着HTML文件)和 /data/images (包含了图片文件). 这要求你编辑配置文件并在http块下的server块中设置设置两个location块。
首先,创建 /data/www文件夹并且放进一个index.html文件,创建/data/images文件夹并且放入一些图片。

接下来,打开配置文件,默认的配置文件已经在server块写好了几个例子,大多数都被注释掉了。

一般来说,配置文件可能包括好几个server块用来区分不同的监听端口和服务器名称。一旦nginx决定哪个进程处理请求,它会测试在URI头部指定的参数是否和server块中location指令定义的参数不一致。
在server块下添加下面的location块:

这个location块指定要比较开头为“/”的URI请求。为了匹配请求,URL需要添加指定相对于根的路径。如果有多个location块匹配到了的话,nginx会选择匹配最长前缀的location。上面的location块指定了一个最短的前缀,所以当所有其他的location匹配失败的时候,这个location将会被使用。

接下来,添加第二个location块:

它会匹配开头为/images/的请求 (location / 也匹配这个请求,但是它是最短的前缀匹配).

最终的结果应该像下面这样。

这已经是一个可用的配置文件了,监听在默认的80端口,可以通过http://localhost/进行访问。
在所有开头为/images/的请求中,服务器会从/data/images文件夹中发送请求的文件。
例如:请求http://localhost/images/example.png的话,nginx会返回/data/images/example.png文件。如果这个文件不存在,nginx会返回404错误。

所有不以/images/开头的请求会被匹配到/data/www文件夹。
例如:请求http://localhost/some/example.html的话,nginx会返回/data/www/some/example.html文件。

为了应用新的设置,请重启nginx:
如果出现了某些异常,你可以尝试在access.log中找到原因,这个文件默认在/usr/local/nginx/logs或/var/log/nginx.

设置一个简单的代理服务器

一个常见的使用场景是nginx作为代理服务器,这意味着nginx服务器接收请求,转为其他服务器,接收结果后再发送给客户端。

我们接下来将会设置一个基本的代理服务器,这个服务器接收图片请求从本地获取文件,其他所有的请求会转给另一个服务器,在这个例子里,所有的服务将会被定义在一个nginx实例中。

首先,通过增加唉一个server块定义一个代理服务器,如下:

这将是一个监听8080端口的简单服务器并且匹配所有请求到/data/up1本地文件夹。创建这个文件夹并且放入index.html文件。注意root指令是放在server上下文下的,当备选location块的路径不包含自己的root指令的时候使用这样的root指令。

接下来,使用上一节的server配置,并更改它作为代理服务器。在第一个location块,增加proxy_pass指令,同时指定被代理服务器的协议、名称、端口。

我们要更改第二个location块的内容,它现在是匹配所有以/images/开头的请求,在/data/images文件夹寻找文件。想让它匹配常见的图片文件,更改成下面这样即可:

这个参数是一个正则表达式,匹配所有以.gif, .jpg, or .png结尾的请求,一个正则表达式应当在前面加个~符号,相应的请求会被匹配到/data/images文件夹。

当nginx选择一个location块处理一个请求时,它首先检查指定了前缀的location指令,记住最长匹配前缀的location,然后检查使用正则表达式的location。如果这里匹配到了使用正则表达式的location,那么nginx会选择使用正则表达式的location,否则就使用之前记住的那个。

最终的配置文件结果如下:

这个服务器会过滤所有结尾是.gif, .jpg, or .png的图片请求并匹配到/data/images文件夹(通过与root指令的参数拼接)并且转发所有其他的指令到上面配置的服务器。

为了应用新的设置,请重启nginx。

这里有更多的指令可能之后会在配置代理连接时用到。

设置FastCGI代理

nginx可以被用来作为路由请求多种框架和语言实现应用的FastCGI服务器,比如PHP。

和FastCGI运行最基本的配置是用fastcgi_pass指令代替proxy_pass指令。并且可以使用fastcgi_param指令设置转发给FastCGI服务器的参数。假设FastCGI服务器在localhost:9000。基于之前设置的代理服务器,用fastcgi_pass指令代替proxy_pass指令,并且更改参数为localhost:9000替换。在PHP中,SCRIPT_FILENAME蚕食是用来确定脚本名称的,QUERY_STRING参数是用来传递查询参数的。结果如下:

这样就设置了一个可以使用FastCGI协议转发所有非图片资源请求到localhost:9000的路由。

Apache2.4中文配置文档1

本文主要翻译一部分常用的apache2.4配置文档,因为之前在搭建个人博客的时候发现2.4的中文文档还还不多。
在某个版本后apache本身的的目录结构有点变化,而网上能搜到的方法很多都是直接更改主配置文件,这样并不好。
以下所有例子均以本站实际需求为例,结合官方文档进行说明。
环境:
Ubuntu14.04 x64
apache2.4

参考内容:
官方文档:http://httpd.apache.org/docs/2.4/zh-cn/
本站配置参考:http://blog.hylstudio.cn/archives/383
相关概念:http://blog.hylstudio.cn/archives/380

apache的初步使用

安装:配置好apt源后,执行sudo apt-get install apache2即可
启动:sudo service apache2 start
重启:sudo service apache2 restart
关闭:sudo service apache2 stop
查看状态:sudo service apache2 status

默认目录

网站根目录:/var/www/html
日志目录:/var/log/apache2
配置文件目录:/etc/apache2
配置文件目录结构如下
├── apache2.conf
├── conf-available
├── conf-enabled
├── envvars
├── magic
├── mods-available
├── mods-enabled
├── ports.conf
├── sites-available
└── sites-enabled

其中可以看到成对出现的文件夹有三对儿,分别是站点、模块、配置。
顾名思义,available下是可用的、enabled下是启用的。
相比直接更改主配置文件apache2.conf来说,修改这些更加方便。
启用的方法为进入到enable文件夹中执行软连接命令,把要启用的内容做个软连接到enabled目录下即可。
比如ln -s ../sites-enabled/000-default.conf .

接下来是常用的功能文档翻译

首先,配置文件的语法描述如下(巴克斯范式)

expr ::= “true” | “false”
| “!” expr
| expr “&&” expr
| expr “||” expr
| “(” expr “)”
| comp

comp ::= stringcomp
| integercomp
| unaryop word
| word binaryop word
| word “in” “{” wordlist “}”
| word “in” listfunction
| word “=~” regex
| word “!~” regex

stringcomp ::= word “==” word
| word “!=” word
| word “<” word
| word “<=” word | word “>” word
| word “>=” word

integercomp ::= word “-eq” word | word “eq” word
| word “-ne” word | word “ne” word
| word “-lt” word | word “lt” word
| word “-le” word | word “le” word
| word “-gt” word | word “gt” word
| word “-ge” word | word “ge” word

wordlist ::= word
| wordlist “,” word

word ::= word “.” word
| digit
| “‘” string “‘”
| “”” string “””
| variable
| rebackref
| function

string ::= stringpart
| string stringpart

stringpart ::= cstring
| variable
| rebackref

cstring ::= …
digit ::= [0-9]+

variable ::= “%{” varname “}”
| “%{” funcname “:” funcargs “}”

rebackref ::= “$” [0-9]

function ::= funcname “(” word “)”

listfunction ::= listfuncname “(” word “)”

端口监听

当apache启动的时候会绑定在本地机器上的一些端口和地址等待请求。默认情况下,它会监听本地所有的地址,然而实际需求可能只需要监听某些特定的端口、特定的地址,或者特定地址上的特定端口。这经常和虚拟主机(Virtual Host)特性结合在一起使用,端口监听决定了apache服务器在不同的IP地址、hostname、端口上如何响应。

Listen指令告诉服务器在特定的地址、特定的端口、或者特定地址的特定端口上接受请求,如果Listen命令仅指定了一个特定的端口,那么服务器会监听所有地址上的这个端口,如果同时指定了IP地址和端口,那么服务器将会监听指定地址上的指定端口,多个Listen指令可以被用来监听指定的多个地址和端口。服务器将会在任意指定监听的地址和端口上响应请求。

例如,如果想让服务器同时在80和8000端口响应请求,使用如下写法
Listen 80
Listen 8000

让服务器在192.0.2.1:80和192.0.2.5:8000响应请求,使用如下写法
Listen 192.0.2.1:80
Listen 192.0.2.5:8000

IPv6的地址必需用方括号括起来,如下
Listen [2001:db8::a00:20ff:fea7:ccea]:80

应当避免重复监听同一个地方,否则服务器启动时会看到下面的错误
(48)Address already in use: make_sock: could not bind to address [::]:80

IPv6相关事宜

越来越多的平台已经实现了IPv6,并且在这些平台上也支持APR、允许服务器申请IPv6套接字连接、处理、发送请求。

对服务器管理员来说一个复杂的因素是apache是否可以同时处理IPv4和IPv6的连接,在IPv6下处理IPv4套接字使用IPv4-mapped IPv6地址,这在很多平台上默认是可以的,但是在FreeBSD、NetBSD、OpenBSD上默认是不可以的。为了遵循操作系统方面的原则,一个特别的配置参数可以更改apache服务器的行为。

另一方面,在某些平台上,比如Linux和Tru64,同时处理IPv6和IPv4的方法有且仅有使用地址匹配。如果你想让apache用最少的套接字链接处理IPv6和IPv4,这要求必需使用IPv4-mapped IPv6地址,使用–enable-v4-mapped 参数即可。

–enable-v4-mapped这个参数除了在FreeBSD、NetBSD、OpenBSD上都是可以的。

如果你只想让apache服务器处理IPv4连接,无论你的平台是什么都可以被支持。使用Listen指令指定一个IPv4地址即可,如下
Listen 0.0.0.0:80
Listen 192.0.2.1:80

如果你的平台支持并且你想用独立的套接字处理IPv4和IPv6连接(例如禁用掉IPv4-mapped addresses),指定–disable-v4-mapped这个配置选项即可。

指定监听协议

监听指令的第二个可选参数是协议,如果没有指定,https默认是443,其他的默认为http,协议是用来决定哪个模块应该处理请求并且可以通过AcceptFilter指令来应用最优化的协议。
只要当你没有使用默认端口的时候才需要指定协议,例如在8443端口使用https协议:

Listen 192.170.2.1:8443 https

怎么和虚拟主机同时工作

Listen指令并没有实现虚拟主机,它仅仅告诉主服务器应该监听什么地址和端口。如果没有使用指令,服务器用同样的方式对所有的请求进行相应。然而可以被用来为一个或多个不同的端口和地址指定不同的行为。为了实现VirtualHost,服务器必须先监听一个地址或端口。在接下来的章节将会介绍使用VirtualHost指定地址和端口来设置不同的行为。注意如果使用了但是没有监听任何端口,那么服务器将不能被访问。

虚拟主机

如果你要调试虚拟主机配置,Apache 的命令行参数 -S 非常有用。即输入以下命令:
/usr/local/apache2/bin/httpd -S
这个命令将会显示 Apache 是如何解析配置文件的。仔细检查 IP 地址与服务器名称可能会帮助你发现配置错误 (参见 httpd 程序文档,以便了解其它命令行选项)。

虚拟主机分为两种,一种是基于名称的,一种是基于IP的
基于IP的虚拟主机:
它使用连接的IP地址来决定正确的主机用来服务,所以你需要为每个主机分配不同的IP地址。

基于名称的虚拟主机:
服务器依赖于客户端在HTTP请求头部报告的hostname来使用正确的主机,使用这个技术,不同的站点可以使用相同的IP。例如本站只有一个公网IP地址,却可以使用blog.hylstudio.cn、files.hylstudio.cn、tomcat.hylstudio.cn等不同的域名来共享一个公网IP地址。

基于名称的虚拟主机通常来说更简单一些,因为你仅需要配置你的DNS服务器解析不同的hostname到正确的IP地址并且配置apache服务器区分这些不同的地址即可。例如本站的多个二级域名都通过A记录解析到了同一个公网IP地址。基于名称的虚拟主机更加适应稀缺IP地址的需求,所以除非你使用的设备确实需求基于IP的虚拟主机,那么就应该使用基于名称的虚拟主机。由于历史原因,基于IP的虚拟主机的需要客户端的支持,现在已经不再适应一般情况下的web服务器了。

基于名称的虚拟主机建立于基于IP的虚拟主机选择算法上,这意味着搜索合适的servername仅会发生在基于IP的主机之间。
在这里主要介绍基于名称的虚拟主机。

服务器如何选择合适的基于名称的虚拟主机

要认识到,很重要的一点的:基于名称的虚拟主机解析的第一步是基于IP的解析。基于名称的虚拟主机解析仅仅是在缩小基于IP的虚拟主机的候选范围之后再选择最合适主机,在基于IP的虚拟主机地址中使用通配符(*)是不合适的。

当一个请求到来之后,服务器会根据请求中使用的IP地址和端口根据虚拟主机的配置参数匹配最佳(最具体)的虚拟主机。如果有一个以上的最佳匹配组合出现,apache服务器会继续比较ServerName和ServerAlias命令指定的名称。

如果你在基于名称的虚拟主机配置中省略了ServerName指令,服务器默认会从hostname得到主机的FQDN(完全合格域名/全称域名)。这种隐式的设置servername可能会导致与预期相反的虚拟主机匹配匹配,并且不鼓励这样。

IP地址和端口的组合的基于名称的默认虚拟主机
如果没有在包括具体IP地址和端口组合的虚拟主机设置中匹配到ServerName或者ServerAlias,那么列表中的第一个虚拟主机将会被使用。

基于名称的虚拟主机 (每个 IP 多个站点)

第一部是在配置文件为每个虚拟主机添加一块,在每个内部,你至少需要ServerName和DocumentRoot命令。ServerName指定指明了服务哪个站点,DocumentRoot指明了这个站点默认展示本地文件系统哪个路径下的东西。

Main host goes away(我实在不知道这段怎么翻译合适了=-=)
任意一个未被存在的匹配的请求都由全局的服务器配置来处理,无论hostname和ServerName是什么。
当你添加一个基于名称的虚拟主机时,如果这个虚拟主机的参数和一个已存在的IP端口组合重复了,那么请求将会由一个具体的虚拟主机处理。在这种情况下,一个机智的做法是创建一个默认的虚拟主机指定一个ServerName来匹配基本的站点。新的域名在同样的接口和端口上,但是要求独立的设置,他们可以作为子虚拟主机(不是默认的)被加入。

ServerName的继承

在每一个基于名称的虚拟主机中最好永远有一个具体的ServerName的列表。
如果一个虚拟主机没有指定具体的ServerName,那么将会从服务器的全局配置文件继承下来。如果没有全局的ServernName,当启动的时候会从DNS反向解析第一个监听的地址。 在这两种情况下,这个继承下来的SserverName会影响基于名称的虚拟主机的解析。所以最好在每一个基于名称的虚拟主机中最好永远有一个具体的ServerName的列表。

例如,假设你已经有了www.example.com,然后你想添加other.example.com虚拟主机,它们解析到了相同的IP地址。那么你仅需要简单的在配置文件中添加以下内容:

# This first-listed virtual host is also the default for *:80
ServerName www.example.com
ServerAlias example.com
DocumentRoot “/www/domain”
ServerName other.example.com
DocumentRoot “/www/otherdomain”

你可以灵活的在指令中星号的位置指定一个具体的IP地址。For example, you might want to do this in order to run some name-based virtual hosts on one IP address, and either IP-based, or another set of name-based virtual hosts on another address.(这句没看懂=_=求大神翻译)
ZHRMoe的翻译(他的博客:http://zhrmoe.com/):
比如,你这么做可以在一个IP地址上运行一些基于域名的虚拟主机(也可以是基于IP的),或者是在其他的地址上运行其他基于域名的虚拟主机。

许多服务想要通过一个以上的名称被访问,这可以通过ServerAlias指令实现。例如在第一个中,ServerAlias指定了一个其他的名称,那么用户就可以使用这个地址来访问同样的网站。
ServerAlias example.com *.example.com

加上这行之后,所有在example.com下的请求都会由www.example.com这个虚拟主机处理。通配符星号和问号可以用来被匹配名称。当然你不能仅仅把名称放在ServerName和ServerAlias后面,首先你要先让你的DNS按正确的规则解析这些域名。

基于名称的虚拟主机的匹配按照在配置文件中的出现顺序处理,第一个匹配到的ServerName或SrverAlias将被使用,它们没有和带通配符的域名没有优先级之分,同样ServerName和ServerAlias之间也没有优先级。所有域名的列表会和ServerAlias同等对待。

最后,你可以其他指令自由设置不同的虚拟主机,大多数指令都可以被使用,这些指令仅改变相关的虚拟主机。要确定一个指令是否被允许只用,检查这个指令的上下文即可。在之外的指令当没有被覆盖的时候会生效。

本站站配置参考

Apache多站点及反向代理 配置

 

CDH5分布式运行任务的各种坑(更新ing)

# CDH搭建、配置(待填坑)

# 角色分配设计(待填坑)

# 参数调优(待填坑)

因为要把edX中Insight的数据导入到一个6节点集群中做运算,所以尝试分离pipline,远程执行分析任务。具体过程有时间另写文章分析(先挖个坑)=-=
今天发现luigi调度任务的时候把任务挂起后就不动了,最开始怀疑luigi配置问题,按官方文档修改metastore_hostmetastore_port均无效
但是CDH的监控显示hive的Server正常运行,查看日志也没看到输出错误,然后我查看了task的源码发现需要从hive中查询数据,所以怀疑hive配置有问题,
hive配置文件由/etc/hive/conf指定,查看/etc/hive/conf指向了/etc/alternatives/hive-conf,而这个文件又是个符号链接,指向了/opt/cloudera/parcels/CDH-5.7.0-1.cdh5.7.0.p0.45/etc/hive/conf.dist
而启动时候发现加载的log4j配置文件是从这里读取的,而其他正常的节点是指向的/etc/hive/conf.cloudera.hive/,所以执行下面命令指向正常的配置

重试hive,成功~
重新执行task,成功~

更好的办法,仿照正常节点的alternatives修复链接

执行

sudo update-alternatives --install /etc/hive/conf hive-conf /etc/hive/conf.cloudera.hive 90

选择hive-conf正常优先级的链接路径即可

sudo update-alternatives --config hive-conf
发现重启集群后依然错误。。。遂删掉之前的
sudo update-alternatives --remove hive-conf /opt/cloudera/parcels/CDH-5.7.0-1.cdh5.7.0.p0.45/etc/hive/conf.dist
待观察是否管用。。。
这次成功了!
——————-
另外当第一个任务的Mapreduce执行后会卡死,但是不用管,耐心等待即可,不知道为啥是在极慢的写入HDFS= =
——————-
另外还发现几个可能卡死的,由于yarn-site.xml配置错误导致连接超时,虽然CDH监控显示正常但是实际是错误的。需要修改/etc/hive/下的配置文件指向正常的ResourceManager。
还有当luigi生成tmp下的临时sql文件传给hive -f执行时,可能由于hive的配置问题假死,重启hive即可、本质原因同上
另外当任务执行一半强行停止时、warehouse下的文件夹一定要手动删除、否则下次虽然会pending一个任务但是却会读取那个空的hdfs文件夹,命令hdfs dfs -rm -r -f /WAREHOUSE_PATH

——————-
关于hdfs权限的设计
hdfs权限依赖于linux权限,常用命令
hdfs dfs -chmod [-R] 3bit权限掩码 文件地址
hdfs dfs -chown [-R] [owner[:group]] 文件地址
我的方案是仿照windows用户体系,设立单独的用户组,对应hadoop。
在hdfs的设置中可以设计supergroup的默认组,可以改成hadoop
dfs.permissions.supergroup, dfs.permissions.superusergroup

另外,如何多人同时共享CDH集群?先挖坑之后再分析
——————————-
hadoop-stream-tool.jar居然是用jdk1.6编译的
而分数统计的一个jar用的是8u65编译的
而我没注意装上的jdk版本是8u31,导致提示major版本不支持= =已经换成大于65的版本重试。。。希望是这个问题,手动微笑
最终在.bashrc下export了JAVA_HOME,问题解决。。是否应该执行hadoop_env呢??

———————————
学生答题分析任务依然报错,根据调用路径猜测又是hdfs权限问题
/tmp/pipeline-task-scheduler/AnswerDistributionWorkflow/
多次实验并且追查hdfs的NameNode日志,发现WARN,mapred和yarn尝试写这个路径,然而它的状态确实755 hadoop:supergroup
所以更改权限和属组
hdfs dfs -chown -R :hadoop path
hdfs dfs -chmod -R 775 path

然而当新创建的目录出现时候权限依然不对,所以查找hdfs默认权限设置,发现了权限的掩码默认为022,那么默认生成的权限就是755

所以更改掩码为002使得默认权限为775,对应xml的dfs.umaskmode, fs.permissions.umask-mode

———————————
小批量数据测试成功,准备导入一年的使用记录进行运行。编写脚本,提交。。。睡觉去了。。。。。
截张监控图保佑我成功~~~
hadoop-zabbix

———————————————

最长的任务居然运行了7小时=-=

目前为止没出现错误。。。。。233333

但是HUE时间显示不正常,更改时区即可。。。

配置文件中如下

# Time zone name

time_zone=Asia/Shanghai

——————————————–
总时间从最开始24小时能跑完。。。截止至今天加cpu和内存前。。。通过优化YARN2参数使得同样的任务需要12小时。。。。。
今天老师把CPU从1核加到了8核,内存从4G加到了8G… 还是三台Worker。。。。速度最终为3小时执行完同样任务,感觉还有优化空间。。。正在试验中,结束后再分析YARN的配置
另外,虽然zabbix的监控看起来高大上,但是CDH自带的生成器的监控图漂亮啊~~如下
附上生成代码
cpu
select cpu_percent where category = HOST;
select cpu_percent_across_hosts where category=CLUSTER;

memory
select physical_memory_used_across_hosts where category=CLUSTER;
select physical_memory_used;

network
SELECT bytes_transmit_rate_across_network_interfaces, bytes_receive_rate_across_network_interfaces where category = CLUSTER;
SELECT bytes_transmit_rate_across_network_interfaces, bytes_receive_rate_across_network_interfaces where category = HOST;

CMmonitor

CAS对接Open edX

Open edX的第三方登录是作为一个django app存在的,配置过程如下。

LMS配置过程

##安装CAS的Client、Mapper
进入edXapp环境,下载CAS的Client、Mapper

CAS Client安装目录在下面的地址

Mapper的安装目录在下面的地址

开启edX特性支持CAS登陆

修改/edx/app/edxapp/lms.env.json文件如下

修改/edx/app/edxapp/edx-platform/lms/envs/common.py如下

同时

修改/edx/app/edxapp/edx-platform/lms/envs/aws.py如下

修改/edx/app/edxapp/edx-platform/lms/urls.py如下

增加一个nextpage属性,当用户通过CAS登陆后自动跳转到dashboard。

修改/edx/app/edxapp/edx-platform/common/djangoapps/external_auth/views.pydjango_cas.views改为cas.view

修改CAS Client配置文件

在cas目录中找到backends.py

默认的Client并没有返回附加的属性,寻找下面的函数

在其返回值增加用户附加属性。也就是代码中的tree。修改如下
原版函数结尾:

改为下面这样:


寻找下面的片段

改为

分析:
username, authentication_response = _verify(ticket, service)这一行是用户认证后返回的用户名和附加属性的XML树。
对接逻辑如下(try之后的部分):
尝试根据用户名获取用户的model。当用户不存在时候,如果设置了自动创建用户。那么就自动根据用户名创建一个用户的model,如果定义了属性解析器、那么根据CAS认证返回的XML树解析用户的属性,对应更改user的model。之后保存model并注册用户。

问题:
1. 是否应该让用户每次通过CAS登陆后都去解析用户的属性来保持edX中用户的资料和CAS系统提供的一致?
2. user和profile的关系是什么?
3. 用户属性的更改是通过更改user还是更改profile?

更改Mapper使其能正确解析CAS Server返回的XML树

修改/edx/app/edxapp/venvs/edxapp/lib/python2.7/site-packages/mitx_cas_mapper/__init__.py

打印源码中的attr结果如下

所以分析、CAS Server返回结果结构大致如下。

修改源代码中原有的XPath、对应实际返回的XML Tag即可正常解析XML

CMS配置过程

开启edX特性支持CAS登陆

修改/edx/app/edxapp/cms.env.json文件如下

修改/edx/app/edxapp/edx-platform/cms/envs/common.py如下,增加一行

修改/edx/app/edxapp/edx-platform/cms/envs/aws.py如下

修改/edx/app/edxapp/edx-platform/cms/urls.py如下

增加一个nextpage属性,当用户通过CAS登陆后自动跳转到dashboard。

修改/edx/app/edxapp/edx-platform/common/djangoapps/external_auth/views.pydjango_cas.views改为cas.view

其他的说明

如果要对CAS返回的结果进行解析,需要更改mapper的代码。在mapper的安装目录下可以看到python脚本。在这里给出一个示例,本校CAS将会返回学号等登录信息,需要自动填写姓名、邮箱。解析脚本参考如下。