2015-07-21 | HeartBleed Ubuntu 修复问题记录

分类 linux 标签 ubuntu   heartbleed   openssl  

    在安装某linux软件的时候,提示我们的服务器上的openssl是有漏洞的版本,需要重新安装一下。到linuxe服务器上查看一下:


dpkg -l | grep "openssl”
openssl                                  1.0.1f-1ubuntu2.8                amd64

    1.0.1f 是HeartBleed的版本之一,需要修复问题。

     1:卸载旧版本的openssl


apt-get purge openssl
rm -rf /etc/ssl

     2:安装新版本的openssl

     安装版本


wget https://www.openssl.org/source/openssl-1.0.2d.tar.gz 
tar zxvf openssl-1.0.2d.tar.gz
./config  --prefix=/usr/local --openssldir=/usr/local/ssl
make && make install
./config shared --prefix=/usr/local --openssldir=/usr/local/ssl
make clean
make && make install

    链接openssl


ln -sf /usr/local/bin/openssl `which openssl`

    查看openssl版本


openssl version

    安装openssl之后,有些以前编译的软件会出现无法使用的情况,报错为:/usr/local/lib/libssl.so.1.0.0: no version information available 需要重新编译一下。

    

     3:OR 打patch的方式来处理

    patch地址:https://launchpad.net/ubuntu/+source/openssl/1.0.1-4ubuntu5.12


wget http://www.openssl.org/source/openssl-1.0.1f.tar.gz
tar -xvf openssl-1.0.1f.tar.gz
wget https://launchpad.net/ubuntu/+archive/primary/+files/openssl_1.0.1f-1ubuntu1.debian.tar.gz
tar -xvf openssl_1.0.1f-1ubuntu1.debian.tar.gz
mv debian openssl_1.0.1f-1ubuntu1
cd openssl-1.0.1f/
patch -p1 < ../openssl_1.0.1f-1ubuntu1/patches/version-script.patch
./config
make
make test
sudo make install

     4: FAQ

     3.1 启动应用报错:

/usr/local/sbin/xxxx: /usr/local/lib/libssl.so.1.0.0: no version information available (required by /usr/local/sbin/xxxx)
/usr/local/sbin/xxxx: /usr/local/lib/libcrypto.so.1.0.0: no version information available (required by /usr/local/sbin/xxxx)
/usr/local/sbin/xxxx: /usr/local/lib/libcrypto.so.1.0.0: no version information available (required by /usr/local/lib/xxxx-server.so)
/usr/local/sbin/xxxx: /usr/local/lib/libcrypto.so.1.0.0: no version information available (required by /usr/local/lib/xxxx-radius.so)

     解决方案:


cd /opt/update/openssl-1.0.2d
make clean
vim openssl.ld
//文件内容
OPENSSL_1.0.0 {
    global:
    *;
};

//编译注意备份 /usr/local/lib/libssl.so.1.0.0 和 /usr/local/lib/libcrypto.so.1.0.0
./config --prefix=/usr/local --openssldir=/usr/local/ssl shared -Wl,--version-script=/opt/update/openssl-1.0.2d/openssl.ld -Wl,-Bsymbolic-functions
make
make test
make install
ldconfig

  提示:编译之后有些系统会导致ssh无法登陆,需要更新把/usr/local/lib/libcrypto.so.1.0.0文件覆盖回原来的版本。

    

    参考文档:

2015-06-11 | 手动清理MAC 文件的方法

分类 review 标签 mac   cache   itunes  
<p>&nbsp;&nbsp;&nbsp;&nbsp; 由于mac平时不怎么重启,还有就是买了iphone6 64G后发现mac的硬盘根本就不够用了,手机和pad的自动备份到硬盘的确耗费了很多资源,使用appcleaner删除一些大的应用后还是不能满足需求,所以只能手动删除不需要的内容。</p>

#### <p>1:清理iTunes中的手机备份文件</p>

<p>&nbsp;&nbsp;&nbsp;&nbsp;iphone或者是ipad连接到电脑,打开iTunes,打开“文件 > 系统偏好设置” 找到设备,删除其中的备份文件。</p>

#### <p>2:清理icloud的备份文件</p>
<p>2.1 查找文件</p>
cd ~/Library
du -sh * | sort -n

<p>2.2 找到大的文件记录,删除移动端备份文件 (如果手动备份了iCloud)</p>
cd Application\ Support/MobileSync
rm -rf Backup

#### <p>3: 清理缓存文件和日志</p>
<p>3.1 清理缓存文件:</p>
cd ~/Library/Caches/
rm -rf *
<p>3.2 清理缓存文件(系统重启的时候会自动清理,当时MAC很少关机重启):</p>
sudo rm -rf /private/var/log/*

<p>3.3 清理临时文件</p>
cd /private/var/tmp/
rm -rf *

<p>3.4 清理Xcode的模拟器文件</p>
cd /Users/longhao/Library/Developer/Xcode/iOS\ DeviceSupport
选择需要删除的模拟器信息

2014-06-07 | java permgen内存泄漏问题处理

分类 review 标签 java   permgen   ibatis   jmap  

    工作以来,第三次出现内存溢出,第一次是ThreadLocal没有remove造成的问题;第二次是ExecutorService没有正确的shutdown造成的问题;这一次的问题在我出手排查之前,已经知道了是permgen在不断的增长,在permgen中主要有Class和Meta信息,常量。

    在开始阶段:排除了ThreadLocal可能导致的问题;排除了Thread可能导致的问题;后面就需要从新的突破点找问题了。

     1:基本设置的排查

    查找日志中访问量较大的请求的URL:

awk '{print $6}' service-digest.* |awk -F"," '{print $1 ",""1"}'|awk -F"," '{a[$1]+=$2;b[$1]++}END{for(n in a)print a[n] " " n }'|sort -n

    查找日志中的调用很多的内容;依然没有发现问题;采用webbench一个个的调用请求来模拟操作,前十名的URL没有发现问题,后面的就没有查看了。

    通过线下操作,发现也不是开始怀疑的RMI远程调用的问题;

    针对CMS-GC,网上建议开通 -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled ,好吧,我们一开始就是开通的。参考:permgen-out-of-memory-reasons

     2:内存使用情况

    2.1:查看内存使用情况

jmap -heap pid

    2.2:查看permsize的命令

jmap -heap `ps -ef | grep java | grep -v grep` | awk 'NR==44,NR==48'

    2.3:触发full gc :

jmap -histo:live pid

     2.4:不断的触发full GC 每10分钟观察一下内存的变化情况

PID=`ps -ef | grep java | grep uic | awk '{print $2}'`
for((i=1;i<10000;i++));do
jmap -histo:live ${PID} > /tmp/fullgc.log
jmap -heap ${PID} | awk "NR==42,NR==48" >> heap.log
echo $i
sleep 600
done

    2.5:观察一段时间后(5个小时),分析相关的permsize的内存增长情况

awk '{if(NR%7==0) print $0}' heap.log

     3:查看perm中的情况

jmap -permstat pid

    查询的结果类似一下情况:

0x00000000ce58bb18 1 3200 0x00000000cc02c030 dead sun/reflect/DelegatingClassLoader@0x00000000f4067700
0x00000000cec33d48 1 3088 0x00000000cc02c030 dead sun/reflect/DelegatingClassLoader@0x00000000f4067700
0x00000000ce39c8b0 1 1944 0x00000000cc02c030 dead sun/reflect/DelegatingClassLoader@0x00000000f4067700
0x00000000ce8ab270 1 3104 null dead sun/reflect/DelegatingClassLoader@0x00000000f4067700
0x00000000ceb1d108 1 3104 0x00000000cc02c030 dead sun/reflect/DelegatingClassLoader@0x00000000f4067700

total = 1600 11325 60491768 N/A alive=1, dead=1599 N/A

    不是反射的问题。(dead sun/reflect/DelegatingClassLoader)

     4:查看JDK的相关垃圾回收情况

    我们使用了CMS GC,过程中发现的GC日志看不出任何问题。

    PS:未来我们找个时间专门讨论一下CMS GC的过程,方便我们在未来的垃圾处理过程中找到更加合理的方法去处理问题。

     5:查看perm中的类加载情况

    在启动的脚本中打开-verbose:class来查看运行的过程中到底多少个类被加载了。【verbose和verbose:class意义相同, 还有-verbose:gc, -verbose:jni】

JAVA_OPTS="${JAVA_OPTS} -verbose:class"

    启动脚本中把输出内容从 /dev/null 2>&1 & 修改为 >${PWD}/jvm.log

    我们通过jvm的日志发现如下奇怪的日志:

[Loaded com.hqb360.uic.dao.point.entity.BonusPointDetail$$BulkBeanByCGLIB$$5a972456_249 from file:/opt/jetty/work/jetty-0.0.0.0-8080-uic.war-_uic-any-/webapp/WEB-INF/lib/cglib-2.2.2.jar]
[Loaded com.hqb360.uic.dao.point.entity.BonusPointDetail$$BulkBeanByCGLIB$$5a972456_250 from file:/opt/jetty/work/jetty-0.0.0.0-8080-uic.war-_uic-any-/webapp/WEB-INF/lib/cglib-2.2.2.jar]
[Loaded com.hqb360.uic.dao.point.entity.BonusPointDetail$$BulkBeanByCGLIB$$5a972456_251 from file:/opt/jetty/work/jetty-0.0.0.0-8080-uic.war-_uic-any-/webapp/WEB-INF/lib/cglib-2.2.2.jar]
[Loaded com.hqb360.uic.dao.point.entity.BonusPointDetail$$BulkBeanByCGLIB$$5a972456_252 from file:/opt/jetty/work/jetty-0.0.0.0-8080-uic.war-_uic-any-/webapp/WEB-INF/lib/cglib-2.2.2.jar]
[Loaded com.hqb360.uic.dao.point.entity.BonusPointDetail$$BulkBeanByCGLIB$$5a972456_253 from file:/opt/jetty/work/jetty-0.0.0.0-8080-uic.war-_uic-any-/webapp/WEB-INF/lib/cglib-2.2.2.jar]
[Loaded com.hqb360.uic.dao.point.entity.BonusPointDetail$$BulkBeanByCGLIB$$5a972456_254 from file:/opt/jetty/work/jetty-0.0.0.0-8080-uic.war-_uic-any-/webapp/WEB-INF/lib/cglib-2.2.2.jar]
[Loaded com.hqb360.uic.dao.point.entity.BonusPointDetail$$BulkBeanByCGLIB$$5a972456_255 from file:/opt/jetty/work/jetty-0.0.0.0-8080-uic.war-_uic-any-/webapp/WEB-INF/lib/cglib-2.2.2.jar]

    uic.dao.point.entity.BonusPointDetail的类一直在perm中增加,每次都在复制,没有重用,也没有被垃圾回收。问题基本就定位到这个地方。

     6:找出问题的具体原因

    6.1:去掉类中的反射,发现问题没有解决。空欢喜了一场!!!!

    6.2:反复的测试调用的页面,发现在插入操作的过程中,会出现步骤5中perm class日志的情况。针对

INSERT INTO bonus_point_detail (
                <isNotEmpty property="id">
                id,
                </isNotEmpty>
               ……
                gmt_created,
                gmt_modified
        )
    VALUES (
               <isNotEmpty property="id">
                    #id#,
               </isNotEmpty>
                    ……
                    now(),
                    now()
    )
    

    这样的情况,我们修改为:

INSERT INTO bonus_point_detail (
                id,
               ……
                gmt_created,
                gmt_modified
        )
    VALUES (
                    #id#,
                    ……
                    now(),
                    now()
    )
    

    后续测试一下,发现问题解决,permgen不再持续增长;当某个内容写操作比较多的时候,直接导致permgen里面有大量的类消息,从而导致了内存溢出。

    待处理:我们将下次讨论为什么不能在insert的时候使用isNotEmpty的问题。

    

2014-04-09 | 团队的标签

分类 review 标签 团队文化   服务意识  

    在卓望的入职培训,HR给我们培训说公司的企业文化就是老板的文化。其实我工作的前几年都是质疑这句话的。后来到了阿里巴巴工作,对比了一下,发现的确如此。对照一下各大公司的企业文化,其实就是创始人的文化。某人给我说:你带的团队最终都会和你一样。当我去实践的过程中,无论是有意识还是无意识的感觉,真是逐步会如此。有一句古话说:“上若好之,下必甚焉”或许也是在表达这个意思。

    去年在团队中推行“服务意识”,其实是给团队打标签的过程,让产品经理和程序员能够走出去发现问题并解决问题,提高大家的主动性。当走近我们的用户并真正体会他们的感受的时候,团队成员也发现自己需要提升的能力,例如:产品可用性,沟通,反馈,驱动落地等,大家在这个过程中得到了锻炼的同时为企业创造了更多的价值。

    我也发现在自己在推行“服务意识”过程中发现的问题,虽然我反复强调,当时依然有人有不一样的回答,比例超过了我的预期。仅仅的强调一个东西是没有用的,需要有监督和探讨对这个内容的理解,否则大家可能对这个问题的理解和行动都可能流于形式。而形式主义是管理的大问题!所以要想出反对形式主义的方式方法来协助更好的推行团队文化的建设。

    团队文化给人展现的效果是一样的,当你问不同的人,他们说出来的意思大致是一样的。而我们遇到的问题是:团队内部对团队文化的理解和说法都是不一致的。有三分之一的人知道,有三分之一的人分析不清楚,有三分之一的人不知道团队文化什么。

    如何解决这个问题?团队多数成员对团队文化不关心的情况下就需要自上而下的反复强调,探讨,总结该如何针对团队文化开展行动。只有反反复复的去强调,大家才可能对某个东西有一定的感觉,然后形成团队的惯性。一旦惯性形成,团队就不需要去再刻意的强调,做事就会有指导思想。开展探讨和总结的目的是更好的监督大家对团队文化的理解,大家相互学习在团队文化方面的具体行动加深印象,后续能够更好的去影响他人,影响新人。

    支援业务发展的工作,能够打造骑兵精神是团队的长期实践的沉淀,需要围绕某个中心来开展团队的建设工作和沟通工作就会逐步形成团队的文化。文化是一种惯性,有了这个惯性,大家开展工作就会更加容易。文化的沉淀需要大家共同努力,管理者在这个过程中需要起到模范带头作用,只有自己做到并从内心接受了这个一致性的文化沉淀,团队才容易在一个方向上前进。从某种程度上,企业文化或者团队文化降低了管理成本,提高了工作效率。

    文化的总结是需要根据发展不断的变化的,在开始阶段提出来的内容可能在发展的过程中并不能真的让整个团队适应,在合适的条件下,应该做整合,减法,逐步形成固有的风格。如果你整天在会议中不断的强调一些固有的东西以示重视,我相信团队成员才会逐步重视起来,只有自己不断的实践,团队成员才可能不断的实践。

    你是什么样子,你的团队就是什么样子!当自己不知道该怎么办的时候,借鉴和微创新可能是很好的出路,^_^

    底线是告诉你不要怎么样,是一种约束;团队文化是一种集体品质,是鼓励。做了不该做的要处罚(我主张越过底线直接开除),做了鼓励去做的事情要奖励。界定清晰,做事就好办了!

    

2014-04-08 | 电商系统运维的设计实践

分类 linux 标签 log   nagios   cacti   sentry   jenkins   rsync   django  

    作坊式的开发的重点是围绕业务开展工作,系统开发出来之后,优化的工作一般都是针对用户端,出现问题一段时间后,有用户反馈才能够发现系统中的业务问题,而有些业务问题其实看看错误日志就可以解决。开发在没有日志反馈的开发环境中,发现问题是被动的。运维人员在这个过程中,也只能被开发驱动去被动解决问题,可能这个问题只是linux配置的问题。为何运维不能及时发现问题通知开发做出相关的调整呢?

    为了更好的反馈问题,我们需要对现有的系统监控做好的同时,做好日志监控。界面化的发布系统目的是降低手动操作错误。

system-administration

     1:硬件监控系统和业务监控

    监控分为系统监控(Nagios),网络监控(Cacti)和业务监控(自主开发)。当系统磁盘满了,I/O的过于频繁,CPU使用率过高,我们通过Nagios的监控给运维人员发送短信提醒来迅速的定位并解决问题。Cacti很好的帮助我们查看系统之间的访问流量情况。

    由于我们的系统上有2个集群,以前系统出问题老是不能确认是哪个集群出了问题,需要手动切换hosts来发现问题,然后做切换。为了解决这个问题,我们把所有的服务的健康状况通过http访问的方式列到一个界面,很直观的展示了线上服务的可用性,方便我们在某集群故障的时候做切换。

    本来以为业务监控做起来比较复杂,后来砍掉相关复杂需求,只要求监控状况的时候,一周开发就搞定了。界面中发现有红色的圈的时候,代表该系统不可用。简单的不能再简单,好用的不能再好用!

     2:日志系统

2.1:系统错误日志的整理

    错误日志的监控使用了sentry,当系统有错误日志的时候,写一份到sentry方便我们分析查看,把各模块的错误日志的解决落实到人,能够快速的定位线上系统的代码bug。错误日志的记录包括:Java系统错误日志,PHP系统错误日志,Nginx错误日志。

    这种错误日志的监控不是实时的,根据系统统计的结果,在2天之内能够解决问题即可。有时候会发现严重的问题,需要及时处理。

2.2:代码执行的慢日志

    代码执行效率低的查询问题,我们系统本来是记录相关的代码执行时间,借用的是taobao的profile,以前我们都是手动去查看哪些慢日志,为了更加的高效,我就找同事写了个脚本来分析一下这方面的代码执行率低的记录,然后通过界面集成到运维系统中去。

    一期项目执行配合的流程是这样的:研发提供相关的脚本→运维负责用django开发后端→前端人员负责美化界面→研发人员测试。在写的过程中没有什么难度,都是很顺畅的利用了现有的资源,把一个手动的需求整合到界面中去了而已。这样做的目的是提高团队的开发效率,更快的反馈性能问题。

    性能的优化是个长期的过程。

2.3:DB的慢日志

    DB的慢日志,通过脚本来读取相关的mysql的慢日志,由运维开发人员集成到运维平台上去。DB的慢日志可以找到我们数据库设计和代码联合查询的问题,对我们优化DB起到合理的反馈作用。

2.4:Nginx的503错误预警

    通过sentry来查看日志并不能及时的发现Nginx的503错误,在系统503错误出现的5秒内,我们需要有一个预警机制来处理后端系统宕机的情况,开始阶段通过脚本来处理,后续考虑使用Logstash来配合分析解决问题。

     3:界面化的发布系统

    部署系统分为2个部分,一个是PHP的部署,以前手动的敲命令,部署时间比较长,出错的机率大,回滚起来不方便,为了解决这个问题,我们分析了整个部署流程,通过界面化的操作来执行发布,大大的提高了效率,降低了出错的情况。在整个开发的过程中,我们只是把手动的工作脚本化和界面化了而已。

    Java的部署采用的Jenkins来完成,又快捷又好用,点一点鼠标,很多事情都通过脚本来搞定了。脚本使用了rsync来Linux hosts之间文件传输。持续集成方面的探索对运维工作效率的提升大有好处,大家不妨去抽空好好的研究一下。

     4:配置管理系统

    目前运维工作中,还缺少一个统一配置管理的工具,我们考虑用zookeeper来解决这个问题。只是配置方面现在已经很少变动了,整个系统还没有到达必须没有配置服务就经常出错的程度,所以还没有动力去做。目前还没有找到一个可以动手开始的配置项目,为了让系统足够的轻,我们暂时选择配置手动。

    在所有的系统运维的工作中,告警机制需要不断的优化,短信,邮件,或者接通其他接口的通知需要及时通知可以处理问题的工作人员,做到监控的实时性。告警的机制需要倾向硬件系统监控和业务监控。

    

    

2014-02-07 | 你只是知道自己工作内容的名词罢了

分类 review 标签 review   管理   学习   沟通  

    给同僚分享一下其他企业的企业文化,特别牛逼的企业(例如:苹果)没有说,因为大家都知道,但是又什么都不知道,容易争论太多。谈了一下IBM,Microsoft,Intel等IT公司,算是聊天式的谈谈而已。这个话题本来应该是HR谈论的内容,我看完关于Amzon的 《一网打尽》 这本书后捷足先登一步,因为Amazon的企业文化有一部分是来自于沃尔玛。于是起了一个分享的名字《他山之石可以攻玉》。

    问题的关键不是分享的内容,而是事后几个人和我说:“你讲的这些词我都知道”,这就遇到了我做技术的时候碰到的同样的问题,你说的知识点我都知道,但是我就是不能解决我们系统问题。碰到这样的情况,一般我都是想骂人,用一句话形容:“送你浅尝辄止四个字都是褒奖你了!”。装逼的先说一下技术,Thread这个东西大家都知道吧,并发编程方面不好好的研究个半年,我就不信你能不搞出内存泄露的问题。“台上十分钟,台下十年功”,没有一些基础方面的锻炼,你顶多就是会一些名字而已。

    关于“客服第一”这个话题,是不是大家都知道。遇到问题的时候,你们的态度怎么样?这不是我们部门管辖的范围;可能你需要找研发处理一下;哦,这个小问题我们过几天就解决了;客户真的太刁蛮了……好吧,外面的用户实在不是你的菜,对内需要做好服务的同仁们,不管是我现在呆的企业还是以前呆的企业,多少人真的存在服务意识其实都是个问号。大公司可能围绕KPI展开工作,小公司可能重人情,所以能够服务好用户就所剩无几了。直到去年最后一个季度,我才发现,“客服第一“是可以要求的,是任何人(至少研发团队是)都可以做到的,而且我发现大家觉得能够服务好他人是一件开心的事情,这简直就是我工作这多年来捞到的宝贝之一。

    还有就是CEO反复重复的稻盛和夫的那句“敬天爱人”,关于“爱人”这一块大家应该都知道是关爱人,这个名词算是很好理解了,我一说可能不是傻子的人都懂了。今天也讲到好几个企业做到了“以人为本”,问题的关键是,你有没有把学习到的这些东西落实到行动中,在工作中,多少次把团队成员的利益放到自己利益的前面?所以,知道这个词对工作毫无指导意义,还真的不如不知道,图个心安理得岂不更好?

    我是一个非常痛恨官僚主义的人,所以,自己算是以身作则,和大家站到一个线上去奋斗,努力的给大家提供一个公平的环境。好吧,看过很多文章谈论IT公司的文化,这个也算是多有接触吧?行动在什么地方?知道名词有个鸟用,转化为行动才是工作的重点,把行动转发为生产力。

    “协作,执行” 这2个词大家都懂吧! 2013年,导师和我说:“你不用对结果负责,所以没有必要在过程中旗帜鲜明的反对,何不支持一下静观其变呢?”。我仔细思量了一番发现,其实自己根本就没有能力为大方向的结果负责,何不去主动配合一下同僚或者是CEO的工作呢?后来我学会了主动合作,这个品质让我感觉自己的工作的阻力越来越小,想推动一些事情的时候反而更加容易的落地。多给别人一些建议,多多的鼓励一下同事们,多美好的事情啊!

    把从别人那个地方学习到的东西落地成为一种团队惯性,这种本事其实是可以学习的,我不反复的强调也不推广是因为这类东西只能给有缘人传授。想学习真本事的人,我不用反复灌输,也会请教我,也会和我探讨,也会很好的落实学习到的内容。我做的事情大家都可以拿走据为己有,因为只要有问题存在,我就有各种机会。

    我们都面对同样的问题:“知易行难”。所有方式方法来源于做事的心态,我当前的心态只能阐述到这种水平,欢迎大家吐槽!!!

    

 
Fork me on GitHub