已经是到北京的第五个年头了,从最开始的想做手机游戏而学习编程,到后来做 Web 开发,又开始做日志分析,接触到了 Hadoop ,最终确定下来自己的技术方向。曾经以为五年的时间,差不多都应该做出自己的产品来,而实际情况却是:一直在用的技术还了解的只是皮毛。所以,虽然在 IT 这个行业已经可以说自己工作了五年时间,但感觉自己还只是刚刚起步,跑在前面的大有人在,自己还要继续努力。
从去年开始接触的 Hadoop ,当时的日志分析已经遇到了瓶颈,用 Hadoop 一试,确实性能提高不少,只可惜,当时的公司因为各方面的原因,开始关注云存储这个方向,虽然即使到了现在我也不太好判定这个战略方向的转变 是对还是错,但是对于当时只是普通员工的我来说,刚好发现了一个实用的技术却没有时间和机会研究、应用,让人都有点恼火。可能像我这样的凡夫俗子,还没有 达到能站在和老板相同高度看待问题的程度,而我能做的,换家公司,找一个能应用自己感兴趣的技术的公司。于是, 2011 年,就又以跳槽开始了。
但 是我并没有想到今年会跳两次,我一直都感觉自己是个踏踏实实的人,但实际情况却是这几年北京这几个同学我换的工作最多。我也很明白:频繁的换工作,害的其 实是自己。每一份工作,都需要花一定的时间去适应,就拿试用期来说,一般的都应该是三个月吧,一年换两份工作,光试用期就半年出去了,真正能踏踏实实做点 事的时间,又能有多少呢?本来在年初换工作时,打算结婚也被拿了出来说事,还想着有上一年的时间,在老家付个首付,没有想到,造化弄人,六月份的时候,一 边看着转正的通知邮件,一边和主管协商着什么时候离职。
但 我并不后悔去了这家公司,虽然只有短短两个月的时间,却让我学到了很多东西,开阔了视野。原来还有这样让人认同的企业文化,原来还有经历这么丰富的同事, 原来还有这么爱带着兄弟们吃喝玩乐的主管,原来程序员的生活,不一定就是加班加班,原来我们可以让自己的生活更精彩。尤其是在去了一趟杭州之后。第一次坐 飞机,下飞机的时候耳膜难受的要死,声音都快听不见了,而我们只有一天的时间,第二天就又要飞回北京,我是想着赶紧休息休息,而同事是一边说着西湖、苏堤 啥的就双眼冒光,大晚上的整个绕西湖走了一圈,没把我累死。不过也确实感受到了和北京不一样的生活方式和态度,那些就在岸边上的茶庄,彰显着和北京烧烤摊 不一样的韵味。只是,当终于下了飞机,换了快轨,出了地铁之后,又一次回到北京的地面上时,我竟然都有种过年时候回到了老家的感觉,原来,在一个城市生活 上一段时间,哪怕只是几年,或多或少的,竟然会产生感情。
可 惜的是,我还没有体会的多深,因为公司内部的原因,我们的项目没用做成,大家因为这个项目聚在了一起,项目没了,大家也就都散了。而且散的那么快,快的都 不可思议。应聘到了一个公司,一个项目做不成,那还可以做别的,一个公司可以有好多项目,而我们这个项目组的成员,明显大家都很有自己的想法,只想做自己 想做的事,而并不是到了一个公司后就开始混日子。那么既然是这样,我想我应该祝福他们,后来一个月后,主管又联系我们聚了一次,大家果然都在做自己擅长、 喜欢的工作,虽然已经不在一个团队,但由衷的为他们感到高兴。
应该说,今年我本来是起了一个好头,在项目组中有这些有着共同理想的同事,但因为中间的变故,团队散了,我也慢慢的走向了堕落。现在回想起来,简直都觉得有点不可思议。
在等待离职的日子里,我看完了《七龙珠》全集,还有《盗墓笔记》,看到最新的更新 ( 当时还没有完结 ) ,每天去了之后就是看漫画、看小说,本来之前因为项目的原因,一个月的时间把 Demo 写的差不多都可以进行演示了,结果变故一来,立马就好像泄了气的皮球一样,什么准备结婚,什么钻研技术,一概不管,完全就把上班当成了去网 吧。自然,白天都成这样了,晚上还期望能老老实实的看书吗,不可能了,再然后,等再到了新公司之后,看书的习惯就怎么也没用再培养起来。
到 了新公司,这个应该老实点了吧,毕竟当时都已经六月份了,半年的时间都已经过去了,如果再折腾折腾,整个一年就过去了,技术这玩意,要说看看书就能学会, 我还真是做不到,必须得有实际的东西去做,在项目上应用,才能快速的掌握。道理也都明白,可就是中间经历了那么一档子事之后,整个人都浮躁了起来,再想回 到以前的状态,真的很难,只能是慢慢的适应。
这 一适应就又是三个月,十一假期时候,交接过来的老版本的日志分析系统出了次问题,正好赶上在唐山参加同学婚礼,三十号下午到的唐山,晚上和同学侃到一两 点,四五点又起来接新娘盘头,参加一天的婚礼下午又坐车回北京,休息了一个晚上之后,从二号早上七点开始恢复数据,一直到三号早上六点,之前也加班搞过通 宵,但像这次这样整还真是头一次,完事之后啥感觉?要说程序写的不好能害死人,程序交接的不好,更能害死人。
假期之后,替换老系统的计划提上了日程,和之前的不一样,也不用再写什么 Demo 先演示啥的,论证已经通过,直接开始用就是。 Hadoop 、 HBase 、 Hive 、 Chukwa 、 Sqoop ,一个都不能少,有很多时候其他组的同事看到我在整 Hive 都奇怪:你们组就每天调 SQL ?
有的时候我自己都快搞不清业务关系,以及写好的 hql 的执行条件,以至于写了一大堆的脚本,而其他同事在某一处想调试时,光这个执行顺序我就得好好解释一遍,突然发现,我现在的这套程序,虽然听 上去比之前老版本的简单,但实际执行的步骤复杂,随着考虑问题的增多,我的脚本也越来越多,慢慢的,可能就和老系统差不多了,只不过,老系统是一个脚本执 行 N 多程序,我是 N 多程序对应着自己的脚本。原来,程序员看别人的程序与看自己的程序,在最开始的时候,是有私心的。
把 HBase 中表的存储空间从 150G 优化到了 120G , hql 分析时间由两个小时优化到了半个小时,好像有那么点成果,可是自己一直对执行效率不是很满意,捣鼓了一个多月一直都没啥进展,直到在和同事的讨论中,听取了别人的建议,再结合自己的业务,存储一下从 120G 优化到了不到 5G ,执行时间也从三个小时优化到了十分钟。但是,这样就已经可以了吗?不行, 2012 ,还得继续。此外,明白了一个道理:和别人多沟通、多分享,比自己一个人埋头苦干要强百倍。
剩下的,对来年做个规划吧, 2012 了,该办的事必须得抓紧时间办啊。
关 于看书,之前看过一篇文章,提到程序员都是自学成才,通过项目,通过好书,尤其是精读一本好书。只是可惜,计算机类的图书,越是好书块头越大,看前头几章 的时候压力最大,“这得啥时候才能看完呢?”虽然这是个错误的观点吧,但有时候还是忍不住会去想,这个时候,毅力、恒心真的很重要,当然,如果是结合项目 需要来看,那就更好了,一边看一边能解决实际问题,这样看书肯定是效率百倍。如果能再按照书中给出的练习强度来检查学习程度,那就更加 OK 了,只是,结合自身实际来看,这个也需要点恒心。
列下书单吧,希望自己能坚持完成。
《深入理解计算机系统》
《 Java 编程思想》
《 C++ 编程思想》
《微积分学教程》
关 于英语,快放假了无所事事时,看到了篇讲如何学习英语的文章,很受启发,英语这玩意,先别说它重不重要,要想学,关键还是看自己有没有兴趣,有兴趣,再结 合合理的学习方法,如果能坚持一段时间,我想,应该是能见到点效果的吧。这个事情想了很长时间,但一直都只是停留在想想的阶段,从来就没有说实际行动过一 次。如果再不抓住这一年的时间,恐怕以后自己会找到更多的借口,所以,把这个也写上吧,一年的时间,说长不长,说短不短,多给自己安排点事,别再留出看漫 画的时间来。
列下目标吧,希望自己能坚持完成。
能看完一本原版英文小说
能听懂一部无字幕英文电影的对白
关于技术, Hadoop 现在只是应用,对它的源码还没有怎么看,接下来打算从比较简单入手,慢慢的,由浅入深吧,希望能对它的底层实现有更加清晰的认识。这个在日常工作中天天都用的到,按说应该是花时间最多的,希望能比前两个成绩多点吧。
目标的话,能分析一遍 Hadoop 及其子项目的源码。
计划列了不少,能全部完成的话还真得拜了佛,但不管怎样,能坚持完成二三,也算是对 2012 有个交代,一年的时间,激情会慢慢消磨殆尽,但如果能时不时的绷紧这根弦,把它养成习惯,或许也就省了烧香了。
数据库安全涉及的问题
数据库安全是当今最重要的问题。您的数据库可能允许顾客通过互联网购买产品,它也可能包含用来预测业务趋势的历史数据;无论是哪种情况,公司都需要可靠的数据库安全计划。
数据库安全计划应该定义:
允许谁访问实例和/或数据库
在哪里以及如何检验用户的密码
用户被授予的权限级别
允许用户运行的命令
允许用户读取和/或修改的数据
允许用户创建、修改和/或删除的数据库对象
DB2安全机制
DB2中有三种主要的安全机制,可以帮助 DBA 实现数据库安全计划:身份验证(authentication)、授权(authorization) 和特权(privilege)。
身份验证是用户在尝试访问DB2实例或数据库时遇到的第一种安全特性。DB2身份验证与底层操作系统的安全特性紧密协作来检验用户ID和密码。DB2还可以利用Kerberos这样的安全协议对用户进行身份验证。
授权决定用户和/或用户组可以执行的操作以及他们可以访问的数据对象。用户执行高级数据库和实例管理操作的能力由指派给他们的权限决定。在 DB2 中有5种不同的权限级别:SYSADM、SYSCTRL、SYSMAINT、DBADM和LOAD。
特权的粒度比授权要细,可以分配给用户和/或用户组。特权定义用户可以创建或删除的对象。它们还定义用户可以用来访问对象(比如表、视图、索引和包)的命 令。DB2 9中新增的一个概念是基于标签的访问控制(LBAC),它允许以更细的粒度控制谁有权访问单独的行和/或列。
客户机、服务器、网关和主机
数据库环境常常由几台不同的机器组成;必须在所有潜在的数据访问点上保护数据库。在处理 DB2 身份验证时客户机、服务器、网关和主机的概念尤其重要。
数据库服务器是数据库实际所在的机器(在分区的数据库系统上可能是多台机器)。DB2数据库客户机是对服务器上的数据库执行查询的机器。这些客户机可以是本地的(驻留在与数据库服务器相同的物理机器上),也可以是远程的(驻留在单独的机器上)。
如果数据库驻留在运行AS/400(iSeries)或OS/390(zSeries)的大型机上,它就称为主机或主机服务器。
网关是一台运行DB2 Connect产品的机器。DB2客户机可以通过网关连接驻留在主机上的DB2数据库。
网关也称为DB2 Connect服务器。安装了 Enterprise Server Edition产品的系统也内置了DB2 Connect功能。
DB2身份验证
DB2 身份验证控制数据库安全计划的以下方面:
谁有权访问实例和/或数据库
在哪里以及如何检验用户的密码
在发出attach或connect命令时,它在底层操作系统安全特性的帮助下完成这个任务。attach命令用来连接DB2实例,connect命令用来连接DB2实例中的数据库。下面的示例展示了DB2对发出这些命令的用户进行身份验证的不同方式。具体如下
用创建 DB2 实例时使用的用户ID登录到安装 DB2 的机器上。发出以下命令:
$ db2 attach to db2inst1
Instance Attachment Information
Instance server = DB2/LINUX 9.7.5
Authorization ID = DB2INST1
Local instance alias = DB2INST1
在这里,隐式地执行身份验证。使用登录机器的用户ID,并假设这个ID已经经过了操作系统的检验。
$ db2 connect to sample user db2inst1 using a
Database Connection Information
Database server = DB2/LINUX 9.7.5
SQL authorization ID = DB2INST1
Local database alias = SAMPLE
在这里,显式地执行身份验证。用户db2inst1和密码a由操作系统进行检验。用户db2inst1成功地连接到示例数据库。
db2 connect to sample user test1 using password new chgpass confirm chgpass
与上例中一样,用户ID db2inst1和密码password由操作系统进行检验。然后,操作系统将db2inst1的密码从a改为chgpass。因此,如果再次发出例 2 中的命令,它就会失败。
DB2身份验证类型
DB2使用身份验证类型决定在什么地方进行身份验证。例如,在客户机---服务器环境中,是客户机还是服务器检验用户的 ID和密码?在客户机---网关---主机环境中,是客户机还是主机检验用户的ID和密码?
DB2 9能够根据用户是试图连接数据库,还是执行实例连接和实例级操作,指定不同的身份验证机制。在默认情况下,实例对于所有实例级和连接级请求使用一种身份验 证类型。这由数据库管理程序配置参数AUTHENTICATION来指定。V9.1 中引入了数据库管理程序配置参数 SRVCON_AUTH。这个参数专门处理对数据库的连接。例如,如果在DBM CFG 中进行以下设置:
$ db2 get dbm cfg|grep -i auth
Server Connection Authentication (SRVCON_AUTH) = KERBEROS
Database manager authentication (AUTHENTICATION) = SERVER_ENCRYPT
那么在连接实例时会使用SERVER_ENCRYPT。但是在连接数据库时会使用KERBEROS身份验证。如果在服务器上没有正确地初始化KERBEROS,但是提供了有效的用户ID/密码,那么允许这个用户连接实例,但是不允许他连接数据库。
下表总结了可用的 DB2 身份验证类型。在客户机---网关---主机环境中,这些身份验证选项在客户机和网关上设置,而不是在主机上。本节将详细讨论如何设置这些选项。
类型 | 描述 |
SERVER | 身份验证在服务器上进行。 |
SERVER_ENCRYPT | 身份验证在服务器上进行。密码在客户机上进行加密,然后再发送到服务器。 |
CLIENT | 身份验证在客户机上进行(例外情况见 处理不可信的客户机 )。 |
*KERBEROS | 由 Kerberos 安全软件执行身份验证。 |
*KRB_SERVER_ENCRYPT | 如果客户机设置是 KERBEROS,那么由 Kerberos 安全软件执行身份验证。否则使用 SERVER_ENCRYPT。 |
DATA_ENCRYPT | 身份验证在服务器上进行。服务器接受加密的用户 ID 和密码,并对数据进行加密。这个选项的操作方式与 SERVER_ENCRYPT 相同,但是数据也要加密。 |
DATA_ENCRYPT_CMP | 身份验证方式与 DATA_ENCRYPT 相同,但是允许不支持 DATA_ENCRYPT 的老式客户机使用 SERVER_ENCRYPT 身份验证进行连接。在这种情况下,数据不进行加密。如果进行连接的客户机支持 DATA_ENCRYPT,就会进行数据加密,而不能降级到 SERVER_ENCRYPT 身份验证。这个身份验证类型只在服务器的数据库管理程序配置文件中是有效的,而且在客户机或网关实例上使用 CATALOG DATABASE 时是无效的。 |
GSSPLUGIN | 身份验证方式由一个外部 GSS-API 插件决定。 |
GSS_SERVER_ENCRYPT | 身份验证方式由一个外部 GSS-API 插件决定。在客户机不支持服务器的 GSS-API 插件之一的情况下,使用 SERVER_ENCRYPT 身份验证。 |
注意:这些设置只对 Windows 2000、AIX、Solaris 和 Linux® 操作系统有效。
在服务器上设置身份验证
在数据库服务器上,在数据库管理程序配置(DBM CFG)文件中使用 AUTHENTICATION 参数设置身份验证。请记住,DBM CFG文件是一个实例级配置文件。因此,AUTHENTICATION参数影响这个实例中的所有数据库。以下命令演示如何修改这个参数。
要查看配置文件中的身份验证参数:
$db2 get dbm cfg
要将身份验证参数修改为 server_encrypt
:
$ db2 update dbm cfg using authentication server
$db2stop
$db2start
注:虽然更新完注册表参数后,直接执行 db2 get dbm cfg|grep -i auth可以看到注册表参数已经修改完毕。但是为使其生效,还是需要重启实例。
某些身份验证类型(比如GSSPLUGIN、KERBEROS 和 CLIENT)要求设置其他数据库管理程序配置参数,比如 TRUST_ALLCLNTS、SRV_PLUGIN_MODE 和 SRVCON_PW_PLUGIN。关于这些设置的更多细节见下文。
在网关上设置身份验证
使用catalog database命令在网关上设置身份验证。在这里的示例中,我们将使用名为myhostdb 的主机数据库。
要将网关身份验证类型设置为 SERVER,应该在网关机器上发出以下命令:
db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate
注意,身份验证不会在网关本身执行。在DB2 Version 8中,身份验证必须在客户机或主机数据库服务器上执行。
在客户机上设置身份验证
我们来考虑两台单独的客户机上的两种情况。我们将一个客户机配置为连接服务器机器上的数据库(DB2 UDB LUW 分布式平台),另一个客户机连接主机上的数据库(例如 DB2 for zSeries)。
连接服务器数据库的客户机: 在针对要连接的数据库的数据库目录项中,客户机身份验证设置必须匹配数据库服务器上的设置(但是 KRB_SERVER_ENCRYPT、DATA_ENCRYPT_CMP 和 GSS_SERVER_ENCRYPT 例外)。
我们假设服务器身份验证类型设置为 SERVER。在客户机上发出以下命令对名为 sample 的服务器数据库进行编目:
$db2 catalog database sample at node nd1 authentication SERVER
注:如果没有指定身份验证类型,客户机将默认使用 SERVER_ENCRYPT。
连接主机数据库的客户机: 我们假设网关上的身份验证类型设置为SERVER。如果没有指定身份验证类型,那么在通过 DB2 Connect访问数据库时假设采用SERVER_ENCRYPT身份验证。身份验证在主机数据库服务器上进行。从客户机发出以下命令会导致客户机向网关 发送未加密的用户 ID 和密码:
db2 catalog database myhostdb at node nd1 authentication SERVER
现在假设网关上的身份验证类型设置为SERVER_ENCRYPT。身份验证同样在主机数据库服务器上进行。用户ID和密码在客户机上进行加密,然后再发送到网关,并在网关上进行加密,然后再发送到主机。这是默认的做法。
处理不可信的客户机
如果服务器或网关将身份验证类型设置为CLIENT,那么这意味着期望客户机对 用户的ID和密码进行身份验证。但是,一些客户机的操作系统没有本机安全特性。这种不可信的客户机包括在Windows 98和Windows ME上运行的DB2。DB2 V9.1不支持 Windows 98 或 Windows ME,但是它支持低版本的客户机,所以仍然可能必须处理不可信的V8客户机。
在 DBM CFG 文件中有两个额外参数,用于在服务器或网关身份验证方法设置为CLIENT,而不可信的客户机试图连接数据库或DB2实例时,决定应该在哪里进行身份验证。这些参数是 TRUST_ALLCLNTS和TRUST_CLNTAUTH 参数。
当服务器或网关身份验证类型为CLIENT 时,除了TRUST_ALLCLNTS和 TRUST_CLNTAUTH 参数之外,还有两个因素会起作用。第一个因素是用户 ID 和密码是否是显式提供的,第二个因素是进行连接的客户机的类型。有三种DB2客户机:
不可信的客户机 :如上所述
主机客户机 :运行在 zSeries 这样的主机操作系统上的客户机
可信客户机 :运行在具有本机安全特性的非主机操作系统(比如 Windows NT、2000、2003、XP 以及所有形式的 Unix / Linux)上的客户机
当身份验证设置为 CLIENT 时
下表总结了如果服务器的身份验证类型设置为 CLIENT,那么在每种类型的客户机向服务器发出连接命令时将在哪里进行身份验证。
是否提供了 ID/密码? | TRUST_ALLCLNTS | TRUST_CLNTAUTH | 不可信的客户机 | 可信的客户机 | 主机客户机 |
No | Yes | CLIENT | CLIENT | CLIENT | CLIENT |
No | Yes | SERVER | CLIENT | CLIENT | CLIENT |
No | No | CLIENT | SERVER | CLIENT | CLIENT |
No | No | SERVER | SERVER | CLIENT | CLIENT |
No | DRDAONLY | CLIENT | SERVER | SERVER | CLIENT |
No | DRDAONLY | SERVER | SERVER | SERVER | CLIENT |
Yes | Yes | CLIENT | CLIENT | CLIENT | CLIENT |
Yes | Yes | SERVER | SERVER | SERVER | SERVER |
Yes | No | CLIENT | SERVER | CLIENT | CLIENT |
Yes | No | SERVER | SERVER | SERVER | SERVER |
Yes | DRDAONLY | CLIENT | SERVER | SERVER | CLIENT |
Yes | DRDAONLY | SERVER | SERVER | SERVER | SERVER |
DRDAONLY 意味着只信任主机客户机,而不管使用 DRDA 进行连接的 DB2 Version 8 客户机。
下面的示例说明如何在服务器和客户机上设置身份验证类型和参数:
在服务器上设置身份验证:
$db2 update dbm cfg using authentication client
$db2 update dbm cfg using trust_allclnts yes
$db2 update dbm cfg using trust_clntauth server
$db2stop
$db2start
在客户机上设置身份验证:
$db2 catalog database sample at node nd1 authentication client
在上面的示例中,如果从任何客户机发出命令
db2 connect to sample
那么身份验证在客户机上进行。如果从任何客户机发出命令
db2 connect to sample user test1 using password
那么身份验证在服务器上进行。
DB2的安全插件架构
DB2 V8.2引入了安全插件的概念。这个概念在DB2 V9.1中得到了进一步增强。通过使用标准的 GSS-API 调用,用户可以编写一个安全插件并将对用户 ID 进行身份验证的工作交给一个外部安全程序。这种方式的一个示例是DB2本身的KERBEROS身份验证。在一台机器上安装 DB2 ESE或应用程序开发客户机时,安装过程中将有一些示例应用程序代码放入实例目录,如果查看 samples\security\plugins 目录,就会看到如何编写安全插件的示例。本节将概述如何在 DB2 安全架构中使用插件,但是不讨论如何编写或编译插件本身。关于这个主题的详细描述,请参考 DB2 UDB 安全性: 理解 DB2 Universal Database 安全性插件 。
Kerberos 身份验证
Kerberos 身份验证为DB2提供了一种无需通过网络发送用户ID和密码的用户身份验证方法。Kerberos安全协议作为第三方身份验证服务执行身份验证,它使用传 统的密码术创建一个共享的密钥。这个密钥成为用户的凭证,在请求本地或网络服务时在所有情况下都使用它检验用户的身份。通过使用Kerberos安全协 议,可以实现对远程DB2数据库服务器的单点登录。
首先,讨论如何设置DB2来使用Kerberos身份验证。如上所述,Kerberos身份验证在DB2 中是使用插件架构实现的。默认的kerberos 插件的源代码在samples/security/plugins
目录中,称为IBMkrb5.c
。在DB2 中使用Kerberos之前,必须在客户机和服务器上启用和支持 Kerberos。为此,必须满足以下条件:
1、客户机和服务器必须属于同一个域(用 Windows 术语来说,是可信域)。
2、必须设置适当的主体(Kerberos 中的用户 ID)。
3、必须创建服务器的keytab文件,实例所有者必须能够读这个文件。
4、所有机器必须有同步的时钟。
可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。
为了在 DB2 中启用 Kerberos 身份验证,必须先告诉客户机在哪里寻找将使用的Kerberos 插件。在客户机上,运行以下命令:
DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE
在这个示例中,使用默认的 KERBEROS 插件。如果使用的Kerberos实现需要特殊功能的话,DBA可以修改这个插件来执行特殊功能。
还可以告诉客户机它正在针对哪个服务器主体进行身份验证。这个选项可以避免Kerberos身份验证的第一步,即客户机寻找它要连接的实例的服务器主体。在客户机上对数据库进行编目时可以指定AUTHENTICATION参数。它的格式是:
DB2 CATALOG DB dbname AT NODE node name AUTHENTICATION KERBEROS TARGET PRINCIPAL service/host@REALM
这一步是可选的。
DB2 CATALOG DB sample AT NODE testnd AUTHENTICATION KERBEROS TARGET PRINCIPAL gmilne/gmilne02.torolab.ibm.com@TOROLAB.IBM.COM
设置 Kerberos 身份验证的下一步是设置服务器。srvcon_gssplugin_list
参数可以设置为支持的GSS-API插件的列表,但是只允许有一个Kerberos 插件。如果这个列表中没有Kerberos 插件,那么自动地使用默认的IBMkrb5插件。如果希望允许所有身份验证(实例连接和数据库连接)使用Kerberos,那么执行以下命令:
DB2 UPDATE DBM CFG USING AUTHENTICATION KERBEROS
或者
DB2 UPDATE DBM CFG USING AUTHENTICATION KRB_SERVER_ENCRYPT
如果只希望 DB2 使用 Kerberos 对数据库连接进行身份验证(对实例连接使用 SERVER),那么执行以下命令:
DB2 UPDATE DBM CFG USING SVRCON_AUTH KERBEROS
或者
DB2 UPDATE DBM CFG USING SVRCON_AUTH KRB_SERVER_ENCRYPT
根据实例的位长度(32 或 64 位),DB2将在实例启动时自动地装载 IBMkrb5 插件。
其他身份验证设置
如果查看 V9.1 实例中的DBM CFG,会看到影响DB2对用户ID进行身份验证的方式的各种设置。正如前面提到的,有针对标准操作系统用户ID身份验证的设置(CLIENT、 SERVER、SERVER_ENCRYPT、DATA_ENCRYPT、DATA_ENCRYPT_CMP),还有将身份验证工作交给外部程序的插件 (KERBEROS、KRB_SERVER_ENCRYPT、GSSPLUGIN、 GSS_SERVER_ENCRYPT)。本节专门介绍其他一些配置变量如何影响对用户的身份验证。
Client Userid-Password Plugin (CLNT_PW_PLUGIN) =
Group Plugin (GROUP_PLUGIN) =
GSS Plugin for Local Authorization (LOCAL_GSSPLUGIN) =
Server Plugin Mode (SRV_PLUGIN_MODE) = UNFENCED
Server List of GSS Plugins (SRVCON_GSSPLUGIN_LIST) =
Server Userid-Password Plugin (SRVCON_PW_PLUGIN) =
Cataloging allowed without authority (CATALOG_NOAUTH) = NO
Bypass federated authentication (FED_NOAUTH) = NO
在上面的列表中,去掉了已经讨论过的参数。
CLNT_PW_PLUGIN | 这个参数在客户端的 DBM CFG 中指定。它指定用来进行客户机和本地身份验证的客户机插件的名称。 |
GROUP_PLUGIN | 默认值是空(NULL)。将它设置为用户定义的插件就会调用这个插件进行所有组枚举,而不依赖于操作系统的组查找。这与后面讨论的授权部分相关。 |
LOCAL_GSSPLUGIN | 这个参数指定默认的 GSS-API 插件库的名称,当数据库管理程序配置的身份验证参数值设置为GSSPLUGIN 或 GSS_SERVER_ENCRYPT 时,这个库用来进行实例级的本地授权。 |
SRV_PLUGIN_MODE | (YES/NO) 这个参数的默认设置是 NO。当改为 YES 时,以 FENCED 模式启动 GSS-API 插件,其工作方式类似于 FENCED 存储过程。FENCED 插件的崩溃不会导致 DB2 实例崩溃。在插件还处于开发阶段时,建议以 fenced 模式运行它们,这样的话插件中的逻辑问题和内存泄漏就不会导致实例崩溃。在确定插件是可靠的之后,应该以 unfenced 模式运行以提高性能。 |
SRVCON_GSSPLUGIN_LIST | 一 个插件列表,当使用 KERBEROS、KRB_SERVER_ENCRYPT、GSSPLUGIN 或 GSS_SERVER_ENCRYPT 时,服务器上的数据库管理程序在身份验证期间将使用这些插件。列表中的每个插件应该用逗号(‘,’)分隔,它们之间没有空格。插件按照优先次序列出,首先 使用列表中的第一个插件对发送的用户 ID/密码进行身份验证。只有当列出的所有插件都返回了错误时,DB2 才会向用户返回身份验证错误。 |
SRVCON_PW_PLUGIN | 在指定 CLIENT、SERVER 或 SERVER_ENCRYPT 身份验证时,这个参数允许用户修改 DB2 用来检验用户 ID 和密码的默认身份验证方法。在默认情况下,它的值是 NULL,因此使用默认的 DB2 方法。 |
CATALOG_NOAUTH | (YES/NO) 默认值是 NO。将这个参数修改为 YES 就允许不属于 SYSADM、SYSCTRL 或 SYSMAINT 组成员的用户修改机器上的 Database、Node、Admin 和 DCS 编目。如果登录的用户使用不可信客户机(定义见上文),或者登录所用的用户 ID 不允许连接数据库或实例,但是用户又必须在客户机上进行编目,只有在这种情况下这个参数才是有用的。 |
FED_NOAUTH | 如 果 fed_noauth 设置为 yes,身份验证设置为 server 或 server_encrypt,联邦设置为 yes,那么在实例上避免进行身份验证。它假设身份验证在数据源上进行。当 fed_noauth 设置为 yes 时系统会发出警告。在客户机和 DB2 服务器上都不进行身份验证。知道SYSADM身份验证名称的任何用户都拥有联邦服务器的 SYSADM 权限。 |
新版谷歌分析增加了好几个实用功能,包括即时分析报告,访问者流(参见《“访问者流”功能添加入Google Analytics中》),还有“多渠道通路分析”。从专业到专家,差别有时候就是一个工具,多渠道通路分析,就是让你变成专家的好工具。之前转发的博客《转发整理:究竟哪种营销手段为B2C网站带来订单》,如果要了解到底哪种营销手段为小明带来订单,用多渠道通路可以很直观的看出来。
单渠道通路分析,在老版本的google analytics已经存在,很多电子商务网站都使用过,如下图:
这 就是常说的可视化通路(或者叫转化率漏斗),4887个用户将商品放入购物车,最后854个用户购买,购物流程的转化率是17.47%。超过80%的用 户,在购物过程中流失了。通过这个漏斗,我们可以分析购物流程哪个环节出了问题,然后改造对应的页面,提升用户购物体验,从而达成更高的转化率。
上 面的可视化通路被称作单渠道通路,对于网站本身的UED(用户体验设计)很有用。那么有没有一种方法,能够帮我们分析出各种推广渠道的效率和效果呢?一个 更直接的问题是:我的EDM电子邮件营销的效果好,还是Google Adwords的效果好呢?或者我该尝试一下社会化媒体facebook?——这就是多渠道通路解决的问题。
多渠道通路谷歌的介绍文字
https://support.google.com/analytics/bin/answer.py?hl=zh-Hans&answer=1191180&topic=1191164&ctx=topic
引用上面文字的定义:
在 Google Analytics(分析)中,转化和电子商务交易会在访问者完成转化后计入引荐该访问者的最近一个广告系列、搜索或广告。但是,在此之前的网站引荐、搜索字词和广告对此次转化有何贡献?访问者从最初表现出购物意愿到最终决定购买,经历了多长时间?
“多渠道路径”报告可以为您展示各营销渠道(即网站流量来源)如何共同发挥作用来实现销售和转化,从而解答这些问题和其他问题。
例 如,许多人可能会在 Google 上搜索您的品牌后,进入您的网站进行购买。不过,他们可能是在阅读博客文章时发现了您的品牌,也可能是在搜索某些产品或服务时发现的。利用“多渠道路径” 报告,您可以了解先前的引荐网址、搜索字词以及在其他渠道的展示对您的销售有何帮助。
我们结合几个实例来看:
上图是多渠道通路的总览界面,位于“转化”-“多渠道通路”-“Overview”
上图的数据可以看出,73.55%的实际购买用户,都是通过自然排名到达的。42.32%的用户,通过直接访问网址的方法到达的。两者加起来超过100%,因为有交集(见红色框)。交集部分有19.9%用户。从这个图可以直观看出购买用户的来源情况。
而在老版本的谷歌分析中,如果一个用户有了购买行为,你只能从数据中观察到这个用户这一次购买的进入途径。举例:某用户第一次在google搜索“cheap gadgets free shipping”,进入了 buyonme.com 网站,然后收藏了这个网站。两天后,该用户通过收藏夹再次访问buyonme.com,然后下了一个订单达成预设转化目标,老版本GA只能统计这个目标来自于Direct Visit,而新版本GA可以追溯历史,判断这个转化目标的实现与当时的搜索有关。
再看看更直观的一个图:
上面的图显示了实际购买用户的购买路径。
排在第一位的是单次自然排名搜索用户,第二位的是直接访问用户(包括收藏夹访问),第三位是用户两次通过搜索引擎自然排名搜索后购买,第四位是用户先搜索找到网站第二次通过收藏夹或直接输入网址产生的购买。
以上数据,对于广告投放策略以及用户购买行为分析,非常有用。
作者: 谭砚耘@用户体验与可用性设计-科研笔记
版权属于: 谭砚耘 (TOTHETOP至尚国际 )
版权所有。转载时必须以链接形式注明作者和原始出处
http://www.webusability.cn/google-analytics-multi-channel-funnels-800/
如果你希望与作者交流,请发送邮件到 tanyanyun/at/163.com 别忘了修改小老鼠
摘要: 0.这个算法实现起来很简单 1.百度百科介绍: Levenshtein 距离,又称编辑距离,指的是两个字符串之间,由一个转换成另一个所需的最少编辑操作次数。 许可的编辑操作包括将一个字符替换成另一个字符,插入一个字符,删除一个字符。 编辑距离的算法是首先由俄国科学家Levenshtein提出的,故又叫Levenshtein Distance。 2.用途 模糊查询 3.实现过程 a.首先是...
这几年如火如荼的国内互联网掀起一个一个的浪潮,社交网站:开心网,人人网,新浪微博。移动手机:iphone,android,开放平台:人人网,百度,腾讯,阿里巴巴。可谓长江后浪推前浪,前浪死在沙滩上。
新浪博客的崛起,源自老徐的博客,明星效应带动,然后大家争相仿效,博客网站一茬又一茬,现在看来,大部分人还是希望有属于自己的博客,而不是依托在别的网站之下。现在最火的blog程序是wordpress
搜狐的天龙八部,史玉柱的征途,引起了国内客户端游戏的热潮,资金一窝蜂的进入了游戏市场。制造了各种各样的2D,3D,2.5D游戏,竞争惨烈。垃圾游戏没人玩?改头换面继续。
开心农场的崛起,直接引起了社交网站与网页游戏的爆发。人人网本来就是社交网站,开始加入了社交应用,腾讯直接做了个朋友系统,各种网页游戏广告铺天盖地,随便打开个网站就弹出一串的webgame注册页面,极尽诱惑之能,勾引玩家。
影视网站也火过一段时间,优酷,土豆,六间房等等,一场版权大战下来,偃旗息鼓了不少。
同样受挫的还有在线文档网站,像百度文库,豆丁网。
iphone推出了App store给广大开发人员带来了福音,随后Android系统疯狂增长,加入移动开发的人员也越来越多,然而成功的很少,大多数在激烈的竞争中落马。
然而最惨烈的还是过去这一年的千团大战。2010年底的时候评估创业项目,团购网站是非常有创意的项目,然后2011年市场证明了那只是烧钱的玩意,多少坚持不下去的网站关停倒闭转行
云计算也是一窝蜂上马,今天山东建立了云基地,明天北京建立了云基地。。。国内市场有那么大吗,我很怀疑,不为别的,就为国内的破网速
微博现在很火,twriter,新浪微博,腾讯微博,应该还会继续一段时间,将来可能会淡定下去。
现在最火的技术词语,不是java,不是c#,而是海量数据,全都在关注这些,热点在哪里,目光在哪里。
然而,最火的不一定就是最好的,一窝蜂进去是抢不到果子的,只能人仰马翻,现在最不缺的就是机遇,只是,我们准备好了吗?