数码兽大冒险 tri 第一章 再会 圣地巡礼

不知道为什么就是非常执着于跑实景 大概每次去东京 台场都会是必修课了吧

跑归跑 拖延症拖了不知道多久一直没有好好整理 于是先对着 Tri 第一章 把舞台实景探访整理了出来

虽然跑了很多地方 但还是没太做好功课 还是缺了一些场景 以往以后还能有机会再去了

0-のぞみ橋
0
首先是第一章BD的封面 这个在 のぞみ橋 桥上拍的

接下来的内容也基本顺延着 第一章 的故事推进整理的

Part 1. 太一从台场家上学

1-のぞみ橋
1
太一从台场出发上学沿途 位置是 のぞみ橋台场侧
2-晴海大桥
2
太一从台场出发上学沿途 位置是 在 晴海大桥
3-%e6%99%b4%e6%b5%b7%e5%a4%a7%e6%a1%a5
3
太一从台场出发上学沿途 位置是 在 晴海大桥
4-%e6%99%b4%e6%b5%b7%e5%a4%a7%e6%a1%a5
4
太一从台场出发上学沿途 位置是 在 晴海大桥
5-%e5%ad%a6%e6%a0%a1
5
太一上学学校外景 位置在 月島

Part 2. 岳、光从学校回家

继续阅读数码兽大冒险 tri 第一章 再会 圣地巡礼

iOS 创意打砖块游戏「Outbreak: Legacy」

我们小时候都玩过弹珠打方块的游戏,在新的时代,打方块游戏又能有怎么样的变化呢,于是从环形轨道出发,便开始游戏制作的探索。于是经过了和小伙伴一块儿一年多的努力,我们的游戏「Outbreak: Legacy」(中文:OO弹球 – 新式环形打砖块)目前终于在苹果App Store发布啦,同时获得“本周新游”推荐。

「Outbreak: Legacy」是一款以新奇砖块嘉年华为主题的环形弹球游戏,通过融入超多的独特创新元素,探索在环形轨道上,操控挡板,反弹共多种技能各异的小球。游戏包含了5个不同主题、数十个精心设计的关卡、并设置了BOSS关与无尽挑战。

更多丰富内容欢迎大家来体验试玩,游戏 App Store下载地址:https://appsto.re/cn/jaCxcb.i

appstore

继续阅读iOS 创意打砖块游戏「Outbreak: Legacy」

忙碌中的 2015 小结

忙忙碌碌,转眼就到了2016,就想着是不是要为已经过去的2015记录点什么。大概是2014过得太过于精彩,进入研究生之后的2015留下的大概就是无止境的瞎忙吧。

米兰行

虽说14年底的时候就开始参与米兰世博相关的项目,但是没有想到15年初能有机会去了一趟米兰。世博会开展前的一周到的米兰,然后虽然基本都在园区里,但是最大的感受不是世博会的宏大,更多的是「这各种没有完工的节奏,这世博真的能按时开始嘛」当然,最后确实是在大罢工和恐怖袭击之后,大门都没有完工的情况下顺利开始了,开园第一天盛大的庆典还是让人欣喜不已。恩,虽然意大利生活节奏出奇的慢,不过意大利面还是很好吃的,每天早上必须的意式浓缩和巧克力蛋糕也超好评(其实就光顾着吃了

expo-staff expo-china expo-event

日本语能力考

虽然一直说自己在努力的学习日语,但是也就一直很缓慢,基本都在学了丢,丢了又捡起来的状态。在一堆学日语的同学里面基本是方面典型。于是乎今年下了狠心,先去考考就跟玩一样的N3试试吧。结果也算是在意料之中,虽然听力和读解基本是满分,不过文法非常惨淡的得了B。唉,还是需要好好努力,正儿八经的去考个N1神马的 orz

jlpt-n3

论文发表

看着曾经的同学一个个在国外期刊发表论文,然而我却一直没敢投论文,在被老师开导了下,试着投了《计算机教育》,虽然在国内都算不上核心,但是收到录用函的那时依旧还是相当兴奋,接着就是在编辑和老师的建议下的反复修改,也算是好好体会了下「论文是改出来的」。

继续阅读忙碌中的 2015 小结

在Docker中使用代理

我们常常会因为下面这些原因需要使用代理:

  • 本机本身访问网络需要经过代理
  • 本地访问Docker Hub过慢需要加速

而Docker本身又是由服务端与客户端构成

作用 使用代理
Docker客户端 用于连接服务端 向服务端发送指令及本地数据 设置代理则会通过代理与服务端进行连接
当我们docker服务端和客户端并不在同一设备上时 docker 使用 https 进行通信,而docker客户端是可能会受到http_proxy、 https_proxy环境变量影响的。可能的原因因为Docker客户端版本不同或者其他原因造成有时会影响有时不会影响

如果在客户端的命令行设置了 http_proxy、 https_proxy 之后,客户端会通过代理链接服务端,此时,如果代理不可到达服务器(比如OSX中docker服务端在本地的虚拟机中,使用Host-only方式与本机链接,如果使用的代理并非本机,则代理无法到达本地虚拟机种的docker服务端),则会导致docker命令无法连上服务端。
在这种情况下,在需要使用docker命令的命令行环境,需要 unset http_proxy 、https_proxy 确保客户端直接与服务端进行连接。

Docker服务端 Docker的执行进程 对外提供接口
执行收到的命令(包含实际访问Docker Registry、Docker Hub)
通过代理进行对应的网络请求
在Bash运行环境中设置的 http_proxy、 https_proxy、 no_proxy docker的服务端并不能识别 参考 Github Issue #402 Using Docker behind a firewall。

 

 

Docker服务端设置代理(加速)

1. 给Docker配置代理

在启动Docker服务端的命令行前直接加入: HTTP_PROXY=server:port

例如直接启动时使用:
sudo HTTP_PROXY=server:port docker -d &

或者在docker的服务启动文件(如:/usr/local/etc/init.d/docker)找到
/usr/local/bin/docker -d,在前面加入 HTTP_PROXY=server:port

2. 使用Daocloud加速器

如果Docker服务器并不需要代理来访问外部网络,仅仅是访问 Docker Hub 过慢的话,还可以考虑 DaoCloud 提供的 Mirror加速器。具体参见:https://dashboard.daocloud.io/mirror

使用 Docker Machine 取代 Boot2Docker 在 OSX 中使用 Docker

原先,我们使用Boot2Docker在OSX下管理Docker。在Docker发布了 Toolbox 之后,新增了 Docker Machine 命令行。通过 docker-machine ,可以让我们以一致化的命令在本地或者云计算上创建 docker 服务。同时很方便的切换 docker 命令对应的目标服务器。

一、安装 Docker Toolbox

Docker Toolbox 安装包包含了:
docker 客户端
docker-machine 工具
docker-compose 工具
Kitematic 一个Docker的GUI

我们可以在 官网 或者 DaoCloud 镜像 下载并安装。

二、将Boot2Docker迁移到Docker Machine

如果原先并没有使用Boot2Docker,可以直接忽略

使用命令:
docker-machine create -d virtualbox –virtualbox-import-boot2docker-vm boot2docker-vm dev
-d virtualbox
使用virtualbox驱动
–virtualbox-import-boot2docker-vm boot2docker-vm
导入virtualbox中boot2docker的vm boot2docker原先在virtualbox创建的虚拟机名字为 boot2docker-vm
dev
可以根据自己需要设置 docker-machine 中的机器名

三、Docker Machine 使用

1. 创建一台新的 Docker Machine

docker-machine create –driver virtualbox default
–driver virtualbox
本机使用的话 使用virtualbox驱动
driver 还可以是amazonec2, azure, digitalocean, exoscale, generic, google, openstack, rackspace, softlayer, virtualbox, vmwarefusion, vmwarevcloudair, vmwarevsphere 等 配置对应的秘钥和参数后 可以直接在云服务中创建设备
default
docker-machine 中的机器名 之后的管理命令均使用该名称

2. 设置环境变量

在创建好 Docker Machine 之后,需要让本地的 docker 客户端了解需要连接的 docker 目标服务器地址,或者在不同的docker服务器之间切换,因此需要设置环境变量。

eval “$(docker-machine env default)”
–driver virtualbox
default
之前创建的machine的名称

3. 使用docker客户端管理docker

当我们将环境变量配置完成之后,我们就可以在本地操作docker一下,使用docker命令管理docker设备了

三、Docker Machine 管理

docker machine 提供了一系列命令来管理对应的docker设备

以下是 boot2docker 与 docker-machine 命令的对照表 使用 docker-machine 时 最后都需要跟上对应的设备名称

boot2docker docker-machine docker-machine description
init create 创建新的docker主机
up start 启动一个关闭的主机
ssh ssh 通过ssh连接到对应的docker主机
save –
down stop 关闭正在运行时的主机
poweroff stop 关闭正在运行时的主机
reset restart 重启正在运行的主机
config inspect 获取主机的参数配置信息
status ls 列出所有主机及其状态
info inspect 获取主机的参数配置信息
ip ip 获取主机的IP地址
shellinit env 设置主机的环境变量
delete rm 删除主机
download –
upgrade upgrade 将主机的docker客户端更新到最新版本

 

 

记一次UnitedStack(有云)平台故障

最近各种云平台事故不断,然而作为喜欢尝试国内各种云的我,也躺枪不断,先是赶上QingCloud的广东机房(广东睿江科技)遭雷劈导致业务中断[故障报告],其次是QingCloud北京2区的网络故障[故障报告],接着是七牛的域名被Godaddy强行clientHold导致的业务中断[故障报告],同时关于七牛还踩到老用户的坑,使得影响非常糟糕,这个有机会另外说。然而这些故障基本都是在工作日的白天出现的,虽然部分恶性故障拖的时间都比较久,对业务影响还是不小,但是也因为用户基数大,同时官方跟进和报告也相对及时,客服也都跟进的比较快,使得问题处理还是相对透明。虽然有人要说「我们要给云计算多一些宽容」但是在使用云服务时候,我们自身也应该做好监控和容灾,鸡蛋都放在一个碗里,迟早还是要出事的。

而下面记述的就是一个并不大的云服务商 UnitedStack(有云)的一次平台故障经历。分为故障线和客服线两条线进行记述。

2015-08-05 01:35
服务器无法访问,ping不通,但是管理平台显示机器正常运行

2015-08-05 01:40
尝试通过管理平台进行重启操作,机器显示正在关机中

2015-08-05 02:10
经过了20分钟管理平台依旧显示关机中,因此提交工单,请求检查机器问题

2015-08-05 02:31
管理平台依旧显示关机中,工单无人响应,尝试联系客服电话,均无人接听,客服电话选择投诉时,接听人表示已经离职。

2015-08-05 02:38
管理平台显示运行中(表示已经重启),但不管管理面板的VNC还是通过网络都无法连通主机。
管理平台本身的其他操作均表现异常

2015-08-05 03:02
主机恢复连通,并且运行正常,检查主机上的业务本身运行也恢复正常

2015-08-05 11:03
技术人员回复工单表示在检查问题

2015-08-05 11:32
技术人员表示多次测试并无发现问题

2015-08-05 11:42
我重新阐述故障期间的具体情况,要求技术人员协助排查问题

2015-08-05 15:03
技术人员答复需要我提供故障主机的相关日志,包括boot.log、dmesg、messages日志等。

2015-08-05 17:24
我打包上传上述三个日志

2015-08-05 19:20
技术人员答复 检查到在故障时间段里,其服务器的连通上出现了问题,造成相关服务异常,目前正在进一步处理中。

2015-08-13 15:53
技术人员答复如下:

我方查到故障期间dell核心交换机出现问题(内存报错),导致我方服务连通出现问题。dell方面也未能查出最终原因。
目前我方正在部署监控,如果故障再次出现,我方可以及时人工干预处理,避免造成更大影响。

整个事件:

故障持续事件:1个半小时,因为在夜间,甚至说如果我完全不管正在睡觉的话,如果没有监控报告根本察觉不到,故障本身影响在可控范围。但是这已经与其在官网上承诺的99.95%的SLA不符(以自然月为单位,不可用时间不超过21分钟),同时在故障期间,工单与客服电话均无人响应,同时初步检查结果并未发现问题所在,故障整理排查与给出答复耗时长达一周多。
UnitedStack SLA

虽然说把这个记述下来并不是表示不满,主要还是希望表达,云计算即使是很复杂的体系,而现在云计算方面的创业公司很多,虽然我们应该多给他们一些信任和支持,但是在出现问题时,对于技术人员值班的问题,以及对于故障的监控上也确实暴露出不少问题,而这些对于传统IDC来说都是基本功的东西,却在云计算服务上确实了实属不应该。

Linux下木马病毒清理小记

昨天下午接到朋友的电话,说其一台业务服务器被机房告知因为大量Out Bound流量,被断网要求清查。因为急于恢复业务,因此需要先进行清理保证机器不再出现恶意流量,恢复网络然后再进行进一步处理。估将主要清理情况记录如下:

首先,登录机器后,发现晨间存在异地登录行为:

last

随后查询历史记录,发现下载并执行了5个恶意的程序,并且添加了启动项

history

5个恶意程序均为二进制文件,尝试将上述5个文件kill,并且删除,并且清除rc.local启动项,但发现程序依旧会继续创建并运行(要那么容易被干掉也就算不上木马了),因此决定进行全盘排查。

首先根据目录的修改时间(万幸病毒并没有篡改自身创建时间),将问题锁定到了下面几个文件(目录):

首先/bin 目录,除开下载的三个文件之外,病毒还用自身替换了 ps 文件 与 netstat 文件,同时创建了数个用于计划任务的启动脚本。(可以预见中了病毒,常用的系统命令早已并不可靠,不但无法用于排查问题,反而会重启病毒)

其次是 /usr/sbin 下的 lsof 与 ss 文件也被替换成了病毒本体。

接着是/etc目录的 crontab 增加了一条计划任务 用于定时重启病毒进程(死灰复燃)
同样/etc/rc.d中的 init.d / rc1.d / rc2.d / rc3.d / rc4.d / rc5.d 下也均增加了病毒的执行脚本
并且取了其实挺显眼的名字 DbSecuritySpt 和 selinux 。

最后在 /usr/bin 目录下面存有一个目录保存有病毒的副本(用于计划任务启动)。

通过各个部分环环相扣,保证任何一个部分即使被删除,或者停止,依旧能够死灰复燃。

清理完成,同时恢复被病毒替换掉的系统文件,把SSH的密码登陆干掉,经过网管监控数小时没有出现异常流量之后,算是暂告一段落。当然,接下来恢复还是迁移业务啊,什么的,就让朋友自己折腾了。

当然其实还是那句话,SSH要改端口,不要用密码登陆啊 →_→

对于上述程序有兴趣的欢迎下载:
链接: 度盘 密码: s9pe

TCG 火焰之纹章0 (Cipher) 中文在线卡片查询

和 @暗黑天马夏澈丹 合作完成的TCG火纹FE0的在线卡查的第一版上线了 虽然界面有些磕碜 但还是欢迎大家来测试 =w=

TCG《火焰之纹章0》中文在线卡查上线啦!

收录了目前为止所有预组、补充包、PR卡的中文信息,官方Q&A,以及游戏规则。

支持电脑端与手机等移动端浏览哦!

《火焰之纹章0》卡查地址:http://fecipher.card.moe

开发:SmdCn 翻译:萨莉雅 (微博:http://weibo.cn/tcgfe)
原作: Nintendo / INTELLIGENT SYSTEMS

2015中国互联网大会小记

自打来帝都以来,大大小小的会参加了不少,有社区干货分享的、还有大谈趋势的,也有产品庆功的、推广吹水的。当然,还有学校里面的各种就数不过来了。基本上每年也都要来北京国际会议中心转两下,但真没想到自己会也有机会参与到这样的活动的组织工作中。

虽说是中国互联网大会,但是其实由互联网协会举办的一个略带官方正气的会议,一到会场,首先看到的中国电信、中国联通、中国移动,也让这个大会多少带了些传统的气息,但在这种全国上下都在高举「互联网+」口号的时候,其实倒也还算应景。当然,还是能在会场看到互联网巨头们以及一些还算有名气的互联网创业公司的身影,还是让人挺欣慰的。

因为学校既是合作方,又承办了这次大会里一个分论坛的缘故,所以在参与学校自己分论坛的筹备和开展的同时,还分到了大会全场志愿者的组织与协调的工作。于是开会前的这两个多月就基本都投入在大会相关的工作中了,而开会的三天加预备的一天更是每天早早起床奔赴会场,晚上回来基本就累成狗了。

大会这几天大大小小各个会场来回跑,也听了包括开幕式在内的各种会,见到了各种领导、嘉宾,但其实就算主会场高唱「五环之歌」我却真的一点感觉也木有,最后整场大会下来,其实觉得我们学校自己的分论坛确是最具有互联网气息的,即有草根投资人的即兴发言,又有学术派院士的演讲,还有来自阿里研究院、乐视的报告。最后的圆桌讨论更是欢乐无穷。一开始看着整个大学其他论坛的情况,我还在想我们这个论坛会来多少人,出乎意料的我们这场不但座无虚席,而且连地上都坐满了人,甚至还有不少人做起了笔记。花了这么长时间准备会虽然比不是那些技术会议全是干活,但是实实在在的内容还是得到了认可其实还是挺让人欣慰的。

cic2015

大会的结束,这个学期也就即将告一段落了,虽然说这个学期没少做事,但各种琐碎又或者涉密的事,实在是压抑的不行。这个假期真是该好好做做自己的side project了