Redis3.2的保护模式

星期四, 2016-10-27 | Author: Lee | linux | 没有评论

Redis3.2的保护模式

针对之前Redis版本,默认无bind和密码设置存在很大安全风险;Redis3.2版本提出新特性protected mode(保护模式)。
如果Redis在启动时,未开启bind和密码设置功能,只能通过回环地址本地访问,如果尝试远程访问redis,会提示以下错误:

DENIED Redis is running protected mode because protected mode is enabled,
no bind address was specified, no authentication password is requested to clients.
In this mode connections are only accepted from the loopback interface.

当然也可直接执行CONFIG SET protected-mode no,关闭保护模式。
类似这种设置在MongoDB3.2或MySQL5.7的默认安全配置都有。

Tags:

Mac系统磁盘空间清理方法

星期一, 2016-10-03 | Author: Lee | computer | 没有评论

Mac同Windows一样,用的时间越久,也会感觉越来越“卡”。 卡顿是高效工作的第一大敌,这里向大家介绍几个简单步骤,保准你的Mac系统” 恢复如新 “。

第一步:磁盘空间清理

大部分Mac用户应该还处于128G磁盘空间下。128G听着挺大,几个月使用下来,App越装越多,再配上几部来不及看的电影,这点空间很容易捉襟见肘。磁盘空间不足不仅仅会让重要的文件无处保存,更会 拖慢 你的系统。原理就不细说了,手段如下:

1.清理应用缓存

简单来说,App运行的时候会生成很多临时的缓存文件,有些App使用频率很低或者已被删除,但这部分磁盘空间却一直占着。这些应用缓存可以直接全部删除,需要时系统会重新生成,这些文件位于目录~/Library/Caches,程序员可以用命令一键搞定,麻瓜按如下步骤:

打开Finder
在菜单栏选择【前往】->【前往文件夹】
输入 ~/Library/Caches
在弹出的Finder里,将所有目录删除
一次性删除数十个文件夹是不是很痛快?保守估计能多出好几个G。

2.清除旧的iOS设备备份

很多用户甚至意识不到自己的iPhone或者iPad备份过多少次,而每个多余的备份又占用了多少额外的空间。这些老旧无用的备份就一直静静的躺在那,看你没空间时干着急。让我们一次全部删除,再做一次干净完整的备份。备份位于:~/Library/Application Support/MobileSync/Backup,非程序员请重复如下步骤:
› Continue reading

Tags:

App推广的那些专业名词儿

星期五, 2016-09-30 | Author: Lee | work-other | 没有评论

看文章总会有人带些貌似高大上的缩写,这里汇总下真实含义,记录如下:

岗位职责篇:

1、CP:不同于娱乐界的胡歌霍建华这种搭档CP,在App推广领域对应,CP是指每个App对应的开发商,意思是App的推广人员。

2、PM:产品经理,对就是互联网公司最危险的那个岗位,经常有段子说被技术和运营联合暴打。

3、UI:在创业公司,也有的被叫成美工,或者P图的,但是他们不会这么理解,每一个P图的心里都是住着一个伟大的设计师的 ,也会和你App推广经常打交道的,会被蠢死。

4、UED:用户体验设计,比较装逼的岗位,就是前段时间百度用户体验总监演讲被喊太low被开除的岗位。包括交互设计师、视 觉设计师、用户体验设计师,用户界面设计师。

5、Operation Manager:运营经理,和你所属的App推广最为接近的岗位,建议:抱团取暖。

App推广中常用名词篇:

1、CPD:两种叫法,1:(Cost per day) 按天计费的广告合作方式,某某广告位一天费用价钱。2,:(Cost per Download) 按下载付费,根据实际下载量收费。
› Continue reading

Tags:

踩坑tomcat8.5的cookie机制

星期六, 2016-08-20 | Author: Lee | JAVA-and-J2EE | 没有评论

tomcat升级到8.5版本

发现登录和退出报错,报错日志为下

[http-nio-8080-exec-20] 2016 Aug 20 12:04:49 WARN  WARN:187 - Handler execution resulted in exception
java.lang.IllegalArgumentException: An invalid domain [.i5a6.com] was specified for this cookie
        at org.apache.tomcat.util.http.Rfc6265CookieProcessor.validateDomain(Rfc6265CookieProcessor.java:181)
        at org.apache.tomcat.util.http.Rfc6265CookieProcessor.generateHeader(Rfc6265CookieProcessor.java:123)
        at org.apache.catalina.connector.Response.generateCookieString(Response.java:989)
        at org.apache.catalina.connector.Response.addCookie(Response.java:937)
        at org.apache.catalina.connector.ResponseFacade.addCookie(ResponseFacade.java:386)

网上已有哥们查看了tomcat的源码 总结规则如下:

domain规则如下
1、必须是1-9、a-z、A-Z、. 、- (注意是-不是_)这几个字符组成

2、必须是数字或字母开头 (所以以前的cookie的设置为.i5a6.com 的机制要改为 i5a6.com 即可)

3、必须是数字或字母结尾

解决之法: 升级处理cookie的domain的地方即可 由 (.i5a6.com 的机制要改为 i5a6.com )搞定

Tags:

防火墙造的孽

星期一, 2016-08-01 | Author: Lee | computer | 没有评论

win 10系统 一定要关闭防火墙

问题一:远程桌面不显示本地磁盘

以前连接的都好好,突然间就不能显示本地磁盘了,依附于此来copy文件的我,顿时傻眼.

要共享的盘勾上了,端口也勾上了,组策略的未配置也改为了禁用,但连接远程桌面还是显示不了本地磁盘

解决方法就是:windows防火墙关掉 (不知道什么时候被开启了)

问题二:SecureCRT 打开连接服务器时 卡死 无响应 困扰了我2个礼拜 一直查不到什么原因

偶尔修复第一个问题,碰巧解决了这个 哎,悲剧

解决方法就是:windows防火墙关掉

Tags: ,

git常用使用简易教程

星期日, 2016-07-24 | Author: Lee | JAVA-and-J2EE | 没有评论

最简单 基本常用的信息 不怎么用记不得的指令 翻录保存

一:安装
下载 git OSX 版

下载 git Windows 版

下载 git Linux 版

二:创建新仓库
创建新文件夹,打开,然后执行

git init

以创建新的 git 仓库。

三:检出仓库
执行如下命令以创建一个本地仓库的克隆版本:

git clone /path/to/repository

如果是远端服务器上的仓库,你的命令会是这个样子:

git clone username@host:/path/to/repository

四:工作流
你的本地仓库由 git 维护的三棵“树”组成。第一个是你的 工作目录,它持有实际文件;第二个是 缓存区(Index),它像个缓存区域,临时保存你的改动;最后是 HEAD,指向你最近一次提交后的结果。

trees

五:添加与提交
你可以计划改动(把它们添加到缓存区),使用如下命令:

git add <filename>
git add *
</filename>

这是 git 基本工作流程的第一步;使用如下命令以实际提交改动:

git commit -m "代码提交信息"

现在,你的改动已经提交到了 HEAD,但是还没到你的远端仓库。


六:推送改动
你的改动现在已经在本地仓库的 HEAD 中了。执行如下命令以将这些改动提交到远端仓库:

git push origin master

可以把 master 换成你想要推送的任何分支。

推送之前和之后 都记得 核查下对应的状态 指令

git status

如果你还没有克隆现有仓库,并欲将你的仓库连接到某个远程服务器,你可以使用如下命令添加:

git remote add origin <server>
</server>

如此你就能够将你的改动推送到所添加的服务器上去了。
› Continue reading

Tags:

互联网公司的标准技术架构–BAT殊路同归

星期四, 2016-06-09 | Author: Lee | JAVA-and-J2EE | 没有评论

本文来源自微信群,记录下以后备用,作为提纲挈领之用.

大部分人对于BAT的技术有一种莫名的崇拜感,觉得只有非常牛逼和天才才能做出现在的这些系统,但经过前面两篇博文的分析,我们可以看到其实并没有什么神秘的力量和魔力融合在技术里面,而是业务的不断发展推动技术的不断发展,一步一个脚印,持续几年甚至十几年的发展,才能达到当前技术复杂度、先进性、牛逼度。

BAT解密(一):聊聊技术发展的驱动力

BAT解密(二):聊聊业务如何驱动技术发展

抛开BAT各自差异很大的业务,站在技术的角度来看,其实BAT的技术架构基本是一样的,再将视角放大,你会发现整个互联网行业的技术发展,最后都是殊途同归。

如果你正处于一个创业公司,或者正在成为另一个BAT的路上而拼搏,那么深入理解这种技术模式(或者叫技术结构、技术架构),对于自己的发展、公司的发展都大有裨益,你将不会再迷茫,你也不再会心里打鼓,CTO将对你刮目相看,CEO将奉你为神明 :)

闲话不多说,有图有真相,看看互联网的标准技术架构是什么样子:

基础平台

上面这张图基本上一网打尽了互联网技术公司的技术点,不同的公司只是在具体的技术实现上稍有差异,但不会跳出这个框架的范畴。

接下来我将逐一介绍每个技术点,包括为什么会有这些技术点,这些技术点的主要场景是什么,这些技术点将如何发展。

存储层技术剖析
1. SQL

即关系数据。前几年NoSQL火了一阵子,很多人都理解为NoSQL是完全抛弃关系数据,全部采用非关系型数据,但事实经过几年的试验后,大家发现关系数据不可能完全抛弃,NoSQL不是No SQL,而是Not Only SQL,即NoSQL是SQL的补充。

所以互联网行业也必须依赖关系数据,考虑到Oracle太贵,还需要专人维护,一般情况下互联网行业都是用MySQL、PostgreSQL这类开源数据库。这类数据库的特点是开源免费,拿来就用;但缺点是性能相比商业数据库要差较多。随着互联网业务的发展,性能要求越来越高,必然要面对一个问题:将数据拆分到多个数据库实例才能满足业务的性能需求(其实Oracle也一样,只是时间早晚的问题)。

数据库拆分满足了性能的要求,但带来了复杂度的问题:数据如何拆分、数据如何组合。这个复杂度的问题解决起来并不是那么容易,如果每个业务都去实现一遍,重复造轮子将导致投入浪费、效率降低,业务开发想快都快不起来。

所以互联网公司流行的做法是发展到一定阶段后,就会将这部分功能独立成中间件,例如百度的DBProxy、淘宝的TDDL。不过这部分的要求很高,将分库分表做到自动化和平台化,不是一件容易的事情,所以一般是很牛逼的公司才会做。典型的有:百度的DBProxy、淘宝TDDL。

如下是淘宝TDDL的结构图(来自果壳网):

淘宝TDDL

2. NoSQL

NoSQL首先体现在数据结构上与传统的SQL的不同,例如典型的Memcached的Key-value结构、Redis的复杂数据结构、MongoDB的文档数据结构;其次NoSQL无一例外的都会将性能作为自己的一大买点。

NoSQL的这两个特点很好的弥补了关系数据库的不足,因此在互联网行业NoSQL的应用基本上是基础要求,要是你听到一个号称自己是互联网公司却连NoSQL都没用,那基本上可以判断是挂羊头卖狗肉类型的。

由于NoSQL方案一般都会自己本身就提供集群的功能,例如Memcached的一致性hash集群、Redis 3.0的集群,因此NoSQL在刚开始应用的时候很方便,不像SQL分库分表那么复杂。一般公司也不会在开始的时候就考虑将NoSQL包装成存储平台,但如果公司发展很大,例如Memcached的节点有上千甚至几千的时候,NoSQL集群就很有意义了:首先是集中管理能够大大提升运维效率;其次是集中管理可以大大提升资源利用效率,2000台机器,如果利用率能提升10%,就是减少200台机器,一年几十万就节省出来了。

所以,NoSQL发展到一定规模后,一般都是走集群路线,当然要发展到这个阶段,一般也是很牛逼的公司才会这么做。

典型的有:Twitter的Twemproxy,豆瓣的BeansDB、腾讯TTC。

如下是Twemproxy的结构图:

Twemproxy

3. 小文件存储

除了关系型的业务数据外,互联网行业还有很多用于展示的数据,例如淘宝的商品图片、商品描述;Facebook的用户图片,新浪微博的一条微博内容等等。这些数据具有3个典型特征:一是数据小,一般在1M一下;二是数量巨大,Facebook 2013年就达到了每天上传3.5亿张的照片;三是访问量巨大,Facebook每天的访问量超过10亿。

由于互联网行业基本上每个业务都会有大量的小数据,如果每个业务都自己去考虑如何设计海量存储和海量访问,效率自然会低,重复造轮子,投入浪费,自然而然的想法就是将小文件存储做成统一的和业务无关的平台。

和SQL和NoSQL不同的是,小文件存储不一定需要公司或者业务规模很大,基本上可以认为业务在起步阶段就可以考虑做小文件统一存储。得益于开源运动的发展和最近几年大数据的火爆,在开源方案的基础上封装一个小文件存储平台并不是太难的事情。例如HBase、Hadoop、Hypertable、FastDFS等都可以作为小文件存储的底层平台,只需要在这些开源方案三再包装一下基本上就可以用了。

典型的有:淘宝的TFS、京东JFS、Facebook的Haystack。

如下是淘宝TFS的架构:

淘宝TFS

开发层技术剖析
1. 开发框架

在系列文章的第2篇《BAT解密:业务如何驱动技术发展》中我们深入分析了互联网业务发展的一个特点:复杂性越来越高。复杂性增加的典型现象就是系统越来越多,不同的系统由不同的小组开发。如果每个小组用不同的开发框架和技术,将会带来很多问题,典型的问题有:

技术人员之间没有共同的技术语言,交流合作少

每类技术都需要投入大量的人力和资源和熟练精通

不同团队之间人员无法快速流动,人力资源不能高效的利用

所以,互联网公司都会指定一个大的技术方向,然后使用统一的开发框架,例如Java相关的开发框架SSH、SpringMVC、Play、Ruby的Ruby on Rails、PHP的ThinkPHP、Python的Django等等。使用统一的开发框架能够解决上面提到的各种问题,大大提升组织和团队的开发效率。

对于框架的选择,有一个总的原则:优选成熟的框架,避免盲目追逐新技术!为什么呢?

首先,成熟的框架资料文档齐备,各种坑基本上都有人踩过了,遇到问题很容易通过搜索解决

其次,成熟的框架受众更广,招聘时更加容易招聘到合适的人才

第三,成熟的框架更加稳定,不会出现大的变动,适合长期发展

以我亲身经历的一个反例为例:我们使用了Play 1作为Java开发框架,因为它是轻量级的Java开发框架,但没想到Play 2直接改为Scala语言开发,Play 1的架构演进停滞,而我们又不能切换为Play 2,结果就导致只能一直用Play 1,有新的需求只能自己开发。

2. 服务器

开发框架只是负责完成业务功能的开发,真正能够运行起来,给用户提供服务,还需要服务器配合。

独立开发一个成熟的web服务器,成本非常高;且业界又有那么多成熟的开源web服务器,所以互联网行业基本上都是拿来主义,挑选一个流行的开源服务器即可。牛逼一点的公司,可能会在开源服务器的基础上,结合自己的业务特点做二次开发,例如淘宝的Tengine,但一般公司基本上只需要将开源服务器摸透,优化一下参数,调整一下配置就差不多了。

选择一个服务器主要和开发语言相关,例如:Java的有Tomcat、Jboss、Resin等,PHP/Python的用Nginx,当然最保险的就是用Apache了,什么语言都支持。

有的人可能担心Apache的性能之类的问题,其实不用过早担心这个,等到你的业务真的发展到Apache撑不住的时候再考虑切换也可以,那时候你有的是钱,有的是人,有的是时间。

3. 容器

容器是最近几年年才开始火起来的,其中以Docker为代表,在BAT级别的公司已经有较多的应用,例如腾讯:腾讯万台规模的Docker应用实践;新浪微博:微博红包:大规模Docker集群实践经验分享等等。

传统的虚拟化技术是虚拟机,解决了跨平台的问题,但由于虚拟机太庞大,启动慢,运行时太占资源,在互联网行业并没有大规模的应用;而Docker的容器技术,虽然没有跨平台,但启动快,几乎不占资源,推出后立刻就火起来了,预计Docker类的容器技术将是技术发展的主流方向。

千万不要以为Docker只是一个虚拟化或者容器技术,它将在很大程度上改变我们目前的技术形势:

运维方式会发生革命性的变化:Docker启动快,几乎不占资源,随时启动和停止,基于Docker打造自动化运维、智能化运维将成为主流方式

设计模式会发生本质化的变化:启动一个新的容器实例代价如此低,将鼓励设计思路朝“微服务”的方向发展。

例如一个传统的网站包括登录注册、页面访问、搜索等功能,没有用容器的情况下,除非有特别大的访问量,否则这些功能开始时都是集成在一个系统里面的;有了容器技术后,一开始设计就可以将这些功能按照服务的方式设计,避免后续访问量增大时又要重构系统。

Tags: , ,

nginx配置https使其达到A+水平

星期六, 2016-05-21 | Author: Lee | linux | 一条评论

前面有一篇文章配置了启用https的安全连接基于LetsEncrypt SSL的nginx配置

在 SSL的安全检测中才获得了B,想达到A+,也很轻松,加下配置文件即可,测试地址:https://www.ssllabs.com/ssltest/index.html

配置如下(nginx.conf):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 server
  {
    listen     192.168.1.1:443 ssl;
    listen     192.168.1.1:80;
    server_name www.iatodo.com iatodo.com;
 
    add_header               Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
    ssl_certificate          /etc/letsencrypt/live/iatodo.com/fullchain.pem;
    ssl_certificate_key      /etc/letsencrypt/live/iatodo.com/privkey.pem;
 
    ssl_ciphers                EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5;
    ssl_prefer_server_ciphers  on;
 
    ssl_protocols              TLSv1 TLSv1.1 TLSv1.2;
    ssl_session_cache          shared:SSL:50m;
    ssl_session_timeout        1d;
    ssl_session_tickets        on;
 
  ......

最后放图 画圈的部分是 Strict-Transport-Security的部分,默认开启https的访问
iatodossl

Tags: , ,

wordpress WP_Image_Editor_Imagick 指令注入漏洞之临时修复

星期四, 2016-05-19 | Author: Lee | php, wordpress | 2 Comments

imagick的漏洞最近闹的沸沸扬扬,我自己一直也没有特别关注,主要是我也没有对应的使用此功能做在线web图片的处理.

有用的情况下也是之前的一个内网项目做过图片的快速处理.

耐不住阿里云的安骑士的 友情提醒我的此漏洞,我惶恐的去查了下服务器的配置根本就没有发现 imagick 的扩展.

具体PHP支持开启 imagick 的扩展可以参照这篇文章 Centos 下编译PHP图片扩展库 ImageMagick、MagickWandForPHP、imagick

但是漏洞还是要修复的,要不老是 邮件 短信提醒的多可怕

提示如下:
漏洞名称:wordpress WP_Image_Editor_Imagick
指令注入漏洞补丁编号:4547205
补丁文件:../wp-includes/media.php
补丁来源:云盾自研
更新时间:2016-05-19 11:06:18
漏洞描述:该修复方案为临时修复方案,可能存在兼容性风险,为了防止WP_Image_Editor_Imagick扩展的指令注入风险,将wordpress的默认图片处理库优先顺序改为GD优先,用户可在/wp-includes/media.php的_wp_image_editor_choose()函数中看到被修改的部分

解决方法:
其实提示的临时修复方式也很简单,我自己没有购买付费服务就按照他的提示自己手工修复下,然后验证下,OK 显示已经修复

1
2
3
4
 $implementations = apply_filters( 'wp_image_editors', array( 'WP_Image_Editor_GD', 'WP_Image_Editor_GD' ) );
 
 //注释掉下面一行,换成上面一行即可,其实就是关闭了Imagick的作为备选项的功能了 easy吧
 //$implementations = apply_filters( 'wp_image_editors', array( 'WP_Image_Editor_Imagick', 'WP_Image_Editor_GD' ) );

Tags: , ,

量子恒道网站统计的关闭

星期日, 2016-05-08 | Author: Lee | JAVA-and-J2EE, linux | 没有评论

早就看到关闭的通知,一直等到过了五一,自己都还没有舍得撤下对应的统计代码,现在彻底看不到统计信息了,
只有去撤掉对应的信息了,也发个小短文聊以纪念感谢陪伴的那多年.

对应网站流量统计,大家知道的可能多是 google统计,百度统计,CNZZ统计等

在当CNZZ还不是很好的时候,选择了恒道,后来恒道又被阿里收购,逐渐淡出统计和数据分析的视野.

对于 量子恒道网站统计将于2016年4月30日正式下线 感觉奇怪又 觉得很正常.

不想多说什么,所有的持续都需要商业行为的支持,聊以纪念下,在大数据盛行的今日,应该有更多的用途.

后续的自己需要撤掉几个网站对应的统计信息.

Tags:

Search

文章分类

Meta