又被Linode小小的坑了一下

昨天早晨起床自己在AWS运行的某项服务很不稳定,查了大半天也没查到有什么问题,弄得满头雾水。

image.png
(图源 :pixabay)

然后下午和朋友聊天时,他提到他在Linode的服务昨晚也出了一些问题,时间段大致和我相同,这就引起了我的兴趣,难道是全球骨干网的故障?

但是浏览了一下邮件,我发现我冤枉骨干网了,因为我发现在那个时间段,我收到几封内容大致如下的邮件:

Your Linode , XXXX, has exceeded the notification threshold (90) for CPU Usage by averaging 135.3% for the last 2 hours.

CPU超限这么多,那么肯定是服务不稳了,不如为啥超限这么多呢?我的程序不能这么废CPU啊,再继续检查邮件,又发现这样一封:

Hello oflyhigh! The following activity has recently occurred:

  • Live Migration - XXXXXXXXXXX GMT

Linode uses live migrations to evacuate hosts for routine maintenance and to rebalance its fleet. These are designed to occur in the background and cause minimal performance impact. No action is required from you, and we do not expect it to cause downtime for the Linode.

擦,这个Live Migration,我并不需要它帮我做什么迁移啊?然后看这对句对性能影响微乎其微(cause minimal performance impact),我去看一下CPU占用图,结果发现类似这样的图形:

image.png

而中间高高耸立的就是他们搞什么动态迁移的时间段!去帮助里找和Live Migration有关的内容,只找到这样一篇文章:

How does a “Live” Migration differ from a “Cold” Migration?

里边倒是没什么实质内容,倒是说了只会在邮件里收到通知,控制面板里不会有通知信息,我去控制面板里找了半天,果然没有。

也就是说Linode在没实现通知我的情况下,搞了个什么对性能影响微乎其微的动态迁移,导致我VPS负载超高。不过考虑到他们邮件里说是为了平衡队列优化性能啥的,我就不去计较了。

image.png
(图源 :pixabay)

至于为什么Linode的故障导致我AWS某项服务的不稳,其实一想也就清楚了,因为我AWS的那项服务依赖于Linode几台VPS提供的服务啊。


This page is synchronized from the post: ‘又被Linode小小的坑了一下’

偶然间发现JUSSI的一个小BUG

I implemented a python library myself, and because I saw that the condenser_api would be deprecated, so in this python library I used other substitution APIs instead of using the condenser_api.

image.png
(图源 :pixabay)

My scripts use my python library and the local node, and they work together without any problems.

But when I tried to use https://api.hive.blog, the following API call went wrong:

network_broadcast_api.broadcast_transaction

And the error message:

{“jsonrpc”:”2.0”,”id”:1,”error”:{“code”:-32603,”message”:”Internal Error”,”data”:{“error_id”:”b39f68b2-729c-4a3d-8c0e-3a55d3ae0559”,”jussi_request_id”:”000136681014195215”}}}

First of all, I thought there was a problem in my script or python library, but when I examined it closely, I found nothing wrong. In addition, I found that using my local node or https://anyx.io, my scripts worked fine.

So what’s the difference between https://api.hive.blog and my local node or https://anyx.io? The answer is https://api.hive.blog using JUSSI.

In order to test this problem, I tested some other nodes, and the results are the same: Nodes with JUSSI enabled return “internal error”, while others handle it normally.

We can use the following steps to reproduce this problem:

Step 1

Make an API Call to https://api.hive.blog (JUSSI enabled)

curl -s --data '{"jsonrpc":"2.0", "method":"network_broadcast_api.broadcast_transaction", "params":{"trx":{"ref_block_num":1097,"ref_block_prefix":2181793527,"expiration":"2016-03-24T18:00:21","operations":[{"type":"vote_operation","value":{"voter":"hiveio","author":"alice","permlink":"a-post-by-alice","weight":10000}}],"extensions":[],"signatures":[]},"max_block_age":50}, "id":1}' https://api.hive.blog

Check the response:

{“jsonrpc”:”2.0”,”id”:1,”error”:{“code”:-32603,”message”:”Internal Error”,”data”:{“error_id”:”b39f68b2-729c-4a3d-8c0e-3a55d3ae0559”,”jussi_request_id”:”000136681014195215”}}}

Step 2

Make API Call to https://api.hive.blog (without JUSSI)

curl -s --data '{"jsonrpc":"2.0", "method":"network_broadcast_api.broadcast_transaction", "params":{"trx":{"ref_block_num":1097,"ref_block_prefix":2181793527,"expiration":"2016-03-24T18:00:21","operations":[{"type":"vote_operation","value":{"voter":"hiveio","author":"alice","permlink":"a-post-by-alice","weight":10000}}],"extensions":[],"signatures":[]},"max_block_age":50}, "id":1}' https://anyx.io

Check the response:

{“error”:{“code”:-32000,”data”:{“code”:3030000,”message”:”missing required posting authority” …

Conclusion

We expect the two nodes to return the same information (step 2 is correct), but step 1 returns:”Internal Error”.

In my opinion, for an API call, whether or not the node is JUSSI enabled, the result should be consistent. So, I think this may be a BUG of JUSSI.

中文版

自己实现了个python库,因为看到condenser_api要被弃用,所以的实现时基本上都是用其它替代API。

使用这个库的程序配合我的本地节点,一直工作的挺好没啥毛病。

不过当我偶然使用https://api.hive.blog, 发现竟然无法处理network_broadcast_api.broadcast_transaction

经过一系列的测试,我决定这个应该是一个BUG,没想到偶然间竟然测出JUSSI的一个BUG。因为指望JUSSI迅速更新是不可能了,只好先自己改一下库喽。


This page is synchronized from the post: ‘偶然间发现JUSSI的一个小BUG’

永久关闭我在STEEM的见证人节点 / Permanently shut down my witness node on STEEM

Last night I was try to run a steem node (v0.23.0) locally for power down operation, but I forgot that my signing key was configured in this node(v0.22.1).

image.png
(图源 :pixabay)

After successfully modifying the power down period, I went to sleep.

Today, I suddenly found out that my local node signed blocks on steem (v0.23.0).

That’s not what I want, I personally don’t support steem v0.23.0 hard fork, and think it’s very unreasonable.

So I decided to permanently shut down my witness node on steem.

PS: Don’t do important operations when you are sleepy in the middle of the night!

中文版

因为硬分叉修改了Power down周期,为了修改自己账户的Power down操作,我打算在本地运行一个STEEM v0.23.0的节点,但是我忘记了我本地的节点上配置有我的出块密钥。

做完修改后,我就去睡觉了。

今天无意中发现,自己STEEM的见证人,竟然使用v0.23.0在STEEM上出块了。

这并不是我的本意,我个人并不支持STEEM v0.23.0 硬分叉,认为他很不合理。

所以我决定永久关闭我在STEEM上的见证人节点,感谢大家一直以来对我STEEM上见证人节点的支持。

——

教训: 半夜不清醒的时候少进行重要操作


This page is synchronized from the post: ‘永久关闭我在STEEM的见证人节点 / Permanently shut down my witness node on STEEM’

再来说说Password和Key的关系 & 账户安全

尽管以前没少聊过关于密码(Password)和私钥(KEY)的话题,但是发现很多朋友(尤其是新加入的)还是有些搞不明白密码和KEY是一个什么关系。

image.png
(图源 :pixabay)

比如说我们一些注册服务提供给我们的都是密码,而网页钱包里虽然也提供或许各种KEY的功能但是只提供修改密码功能而不提供修改KEY功能。

所以很多用户觉得密码就是最高权限,还有一部分用户认为密码就是OWNER KEY。这两种错误认识,我刚加入的时候也有过这样错误的认识,经过了这么多年总算搞明白一些了。

KEY 是HIVE/STEEM 工作的基石

首先,说明一点KEY是HIVE/STEEM 工作的基石。

从性质上区分,KEY分为公钥(Public KEY)和私钥(Private KEY),二者成对出现,通过私钥可以计算出公钥。私钥用于签名,公钥用于验证。

HIVE/STEEM区块链上只保存用户的公钥,而私钥保存在用户自己手中

用户发文/点赞/转账/修改权限时,用私钥签名操作数据,然后广播数据到区块链。

区块链程序(见证人节点)根据用户账户的公钥验证签名是否合法,然后处理合法签名的请求,将数据写入到区块链中。

KEY分不同的权限等级

因为发文、点赞等操作要频繁地使用到KEY;转账/投见证人票/投提案等操作操作频度会略低但是一旦KEY泄露资金等将不再安全;而修改账户对应KEY的更是需要更高的安全性,否则账户就会轻易易主。

为了解决这些问题,HIVE/STEEM中设置了不同权限等级

image.png

简单来讲,权限级别高的KEY可以做权限级别低的KEY能做的事情,反之则不可以。所以权限级别越高的KEY就越要保证安全不可泄露。

比如你泄露了POSTING KEY,那么对方可以拿来发文、点赞等;你泄露了Active key,对方就可以动用你的资金;你泄露了Owner KEY,对方就可以对这个账户为所欲为了。

(MEMO KEY属于另外的情况,可以参考我以前关于MEMO KEY的文章)

Password 与KEY的关系

按我们之上的描述,其实并没有Password什么事情,事实上也确实如此,整个工作流程并不需要Password的存在

然而很多新手用户对KEY的概念比较懵圈,而在传统的网站应用中,Password是最常被使用的概念,所以为了方便用户,就有了Password的存在。

简单来讲,Password和我们平时用的Password没什么区别,就是一串字符组成的密码。

一些钱包的注册服务会用使用Password按一定的规则来获取四组公私钥对,然后用把对应的私钥给用户,并用对应的公钥去在区块链上注册账户。

一些应用(包括网页钱包等)会用Password来获取对应的私钥(Private KEY),这样操作起来就等同于使用对应的私钥操作了。

所以说,Password是生成、记忆、使用私钥的手段之一,而不是唯一手段

HIVE/STEEM区块链本身和Password是没有一丁点关系的,只是外围应用(按着相同的规则)在使用Password。我们完全可以在所有环节脱离Password而只使用KEY。

账户注册的安全性

另外顺便说说大家很关心的账户注册的安全性。

需要说明的是HIVE/STEEM区块链上,私钥意味着和账户相关的一些内容,所以账户的安全基本上可以理解成私钥的安全,这涉及到注册、保管、使用等诸多方面,我们只说注册。

账户注册服务其实只需要公钥,所以原则上我们提供给对应的服务公钥即可。但是很多用户并不清楚如何生成公私钥对,所以很多时候账户注册服务就肩负起这个责任。

账户注册服务生成公私钥对一般有几种方式:

  • 用户设置密码,本地使用脚本+密码生成公私钥,然后使用公钥注册
  • 脚本生成密码,本地使用脚本+密码生成公私钥,然后使用公钥注册
  • 用户设置密码,服务端使用密码生成公私钥并用公钥注册
  • 服务端生成密码,并使用密码生成公私钥并用公钥注册

那么判断安全性与否的一个原则就是:密码/私钥是否会经过服务端。如果经过了服务端,那么就会存在安全隐患。

其实使用密码/私钥的时候也是这个判断原则,就是:密码/私钥是否会经过服务端

以hive(https://wallet. hive.blog)的网页钱包,以及https://hive.blog应用为例,***注册的时候都是使用脚本在本地生成的对应密码和私钥等,使用的时候也是如此,所以原则上是安全的。***

当然原则上安全并不表示一定安全,比如:万一升级了代码呢?万一代码库被黑了呢?万一你的浏览器中招了呢?万一你登录的其实是一个假的网站呢?等等等等。

关于修改密码

说了这么多,你可能有些担忧,我的账户(密码、私钥等)有没有风险呀?要不要改个密码?

大多时候你如果都是选择的官方服务/应用,那么可以不必有此忧虑(但是也不排除官方服务有BUG或者被黑之类的)。

现在我们要讨论的问题是,改密码就一定安全吗?大多数人修改密码也是要用一些网页钱包或者手机钱包等,谁又能保证这个修改过程中你的密码/私钥不经过服务器呢?

所以最安全的方式是自己写代码去改确保整个过程中密码和私钥不经过网络。比如自己在一台离线的电脑上生成公私钥对。然后去联网的电脑上用公钥去修改密码。

image.png
(图源 :pixabay)

想想就头大是吧?我也头大。欢迎大家留言一起讨论呀。


This page is synchronized from the post: ‘再来说说Password和Key的关系 & 账户安全’

test

just test


This page is synchronized from the post: ‘test’

和过去说拜拜

今天整理一台服务器上的资料,发现这个服务器上的资料出奇地多,想想也就明白了,这么多年,每当我关闭一台旧服务器,就会把一些我觉得重要的资料迁移到新服务的一个备份目录里。

image.png
(图源 :pixabay)

就这样资料越攒越多,占用的空间也越来越大,看一下这台服务器我这个备份目录里的东西,竟然多达137G,喔,这可不是一个小数目啊。

image.png

其实这么多年不止一次想把这些资料清理一下,毕竟已经过了好多年,有些当初我觉得很重要的东西其实并不是那么重要,这些数据最长的有十五六年没有动过了。

但是总觉得一段数据代表着一段过往,删除掉了数据,是不是等同于删除掉这段过往呢?那最终我们的记忆是不是也会一片空白?回忆过去的时候,再也没有值得回味的东西了呢?

比如这个叫做hdxxx的目录,是04年的时候为一帮初中生创建的网站,一帮少男少女在这个网站上玩得不亦乐乎,办活动、出杂志、搞聚会等等等,连带着我都觉得自己年轻了很多。

又比如这个叫做visaxxx的目录,是我和别人合作做的一个移民咨询项目,说起来好笑,对移民一窍不通的我,竟然和别人做这样的项目,当然了我只负责一些网站什么的,不过后来合伙人移民加拿大了,这项目也就黄了。

还有这个lovexxx的目录,是帮别人弄得一个网店项目,这个网店曾经在淘宝相关类目下排名前三,差一点就做到了皇冠。虽然现在遍地都是几皇冠的店铺,但是在不刷单的情况下,凭真实销量做上去,还是很不容易的。

还有这个ioxx的网站,曾经是国外下载站某重要类目TOP3的存在,我全权负责服务器以及服务器端软件的开发,包括用户管理、在线注册等等等等,可以说耗费了大量的心血。

一个个目录一个个压缩包的检查下去,发现每个目录的故事都能自我感觉很精彩的,都能说上半天的。不过这些都是只能是故事了。

hdxxx里的孩子们都已经长大了,有的做了建筑设计,有的做了银行职员;visaxxx的那个朋友在加拿大每天晒她的豪宅和大庭院;lovexxx那个店铺已经沉了底,被无数后来者超越;ioxx上了市相关人员也换了一批又一批…….

这些曾经我生活中最重要的部分,其实现在大多都与我没什么太大的关系了。再把这些数据复制来复制去也没有什么太大意义了,那么就不如都删除了吧。

image.png
(图源 :pixabay)

有些事在记忆留一个影子/印记就好,过于沉浸在回忆中还怎么发展?人总是要向前走向远看的。那就和过去(或者说一段时间之前的过去)说拜拜吧,rm -rf *直接搞定收工。


This page is synchronized from the post: ‘和过去说拜拜’

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×