lss233 8 min read

有句俗语叫:If it ain't broke, don't fix it. 今天真是见识到了。

0x0000 起因

在昨天(2月8日) 17时,本人收到了Cloudcone发来的春节优惠邮件。

在一番激烈的思想斗争下,下单了一个看上去更便宜的套餐。打算把服务器迁移过去。

0x0001 噩梦

几分钟后,服务器创建完毕。

发现控制面板居然没有像搬瓦工那样方便的服务器迁移菜单,自己又懒得手动迁移,于是就发了份工单给客服询问有没有什么办法。

17:30

技术人员小哥开始帮我迁移数据。

他的操作非常简单粗暴,直接把旧服务器的硬盘挂载到新服务器上,再把新服务器的硬盘挂载到旧服务器上。

听起来是没什么问题,那位小哥也没继续回复我。

然而他没有料到,两台服务器的IP地址是静态设置的,写死在`/etc/networks/interfaces`里,这位小哥没有给我改过来,这导致两台服务器都不能访问网络。

无奈之下,我只好回复他,请他帮忙修改地址,顺便帮我调整好硬盘大小。

次日0:00

距离我的回复已经过去3个小时,

那位技术人员小哥没有回复

见鬼了,怎么办?!

我打开面板,看见有一个开启IPv6的选项。 开启IPv6应该会重新配置网络,说不定能把IP问题修好呢?

抱着侥幸的心理,我点了。服务器重新启动。

几分钟后,成功了。服务器可以上网了!

然而,咱又遇到了新的问题。这个服务器的IP地址比较特殊,它在国内访问会显示连接超时,而在其他地方却没有问题。很明显,这个服务器的IP被[数据删除]了。

0:30

我还没有睡。在百度上稍微搜索了一下,得到两种解决方法:

  1. 删除服务器,重新购买。
  2. 发工单申请更换IP,但需要$2。

由于之前的技术小哥帮我把硬盘挂载在了新服务器上,如果直接删除,那么数据也肯定跟着一起没掉了,所以排除方法1。

我创建了一个Urgent工单,申请更换IP,。

几分钟后

很快,就有一个工程师回复我了。他是这样说的:Your request is sent to our network team, please allow some time while they get it processed for you.

我的内心:诶,不错啊这服务态度。

抱着侥幸的心理,我在这个工单里问能不能帮我把硬盘大小的问题也给处理了。

我刚刚回复完。刷新了一下浏览器,就看见另外一个工程师回复我:Your request is sent to our dev-ops team, please allow some time while they get it processed for you.

我:???

完了。这俩人是机器人没跑了。

看自己的账户,$2也没有扣掉。先睡觉吧,说不定明天早上就好了呢。

睡之前回复了一句:Thank you, please be quick. My service have been shutdown for over 8 hours, my users are complaining, please understand.

10:00

我大概是这个时候醒的。登录网站看看情况解决了没有。

最早帮我迁移的小哥还是没有回复我。第二个工单在我回复没多久之后就回复了一句:你可以在我们dev-ops回复之前照常使用你的服务器。

照常个鬼啊,根本用不了啊。这都什么鬼回复模板。

11:00

不等了,估计他们是打算直接把我凉着了。

现在我有两台服务器:

  1. 本来就有的一台 chocolate,挂载硬盘30GB,无法访问网络。
  2. 前面下单的一台 darksky,挂载硬盘25GB,可以访问网络。

想了一个简单的思路:

  1. 重新安装chocolate上的系统,腾出空间。
  2. 使用 ssh 和 dd 把 darksky上的硬盘复制到 chocolate 上。
  3. 删除 darksky。
  4. 重新下单一台服务器。
  5. 把在chocolate上的数据迁移到新下单的服务器上。

看上去挺简单的,就像写程序的时候交换两个变量一样。

11:18

下单了新的服务器,系统安装好之后惊呆了,IP地址和之前的居然是一样的。

删除,重新下单。

又是一样的。

看来他们还是按顺序提供分配IP的,也就是说,必须要有一个倒霉鬼下单得到那个IP之后,我下单才会得到新的IP。

这大中午的,谁会买啊。

11:22

我想到了一个绝妙的好主意。

先下单一个价格最低的服务器,它会分配到那个不能用的IP。再下单我想要的服务器,这样就可以啦!

0x0002 第二个噩梦

复制数据很简单是吧?我一开始也是这样想的。

在百度上搜索了一下,原来有种东西叫 SSHFS。 它可以通过SSH协议把远程的服务器挂载到本地上。

于是我的做法是:把硬盘镜像mount到chocolate/mnt上,再通过SSHFS把chocolate/mnt 挂载到新服务器的 /mnt上。

11:52

重启新服务器,发现使用旧的用户名和密码可以登陆。

太棒了!

诡异的事情来了,登陆成功之后,还没有看见bash,就重新退回到登陆界面了。现在想想,应该是某个支持库没有复制过来,导致bash无法启动。

看来SSHFS这条道不行,重新安装。 对了,新的服务器叫vanilla。

很久以前曾经用tar配合netcat迁移过数据。通过管道,分别在发送端和接收端执行:

# 接收端
netcat -l -p 7000 | tar x
# 发送端
tar cf - * | netcat 接收服务器 7000

试试吧。

14:46

我把MobaXterm自带的小游戏玩了个遍。终于知道为什么一个好好的终端软件带这么多游戏干什么了。

我重试了好几次,每次都是执行到一半,ssh断开连接,Vanilla整个系统无法响应。

看来这个方法也是不行了。应该是因为在覆盖的某个重要lib文件的时候整个系统崩溃。

这个服务商提供的服务器都是KVM,可以访问Recovery模式,看来只能用这种方法了。

Recovery模式和Windows的PE系统差不多,是挂载到内存上的系统。因此我们怎么修改硬盘都和它没有关系。

16:00

Recovery的系统可真是简洁。没有apt,也没有gcc。这意味着我用不了SSHFS这种方法了。

不过ssh和scp倒是能用。我挂载了本地硬盘,使用scp把远程上的服务器复制到本地。

问题#1

SCP复制的时候进度一直是0%,而且最后的文件大小居然超过了25GB!

一看才发现,整个程序卡在复制虚拟设备 /dev/core 上。

问题#2

历尽千辛万苦终于复制完数据,回到面板把Recovery模式关闭。这个按钮点了半天没有反应。他们面板的开发人员怕不是写了个假的按钮吧。

好在本人对Html和JavaScript也略知一二,打开F12看了一下,是一个表单。手动执行一下submit();完事。

16:15

成功进入系统了,但是发现好像少了很多东西,和没有复制几乎没区别。

什么玩意啊。

无奈,还是只能走SSHFS的方法。

0x0003 重新上线

功夫不负有心人,在走了N次弯路之后,服务器终于恢复正常了。

16:25

在复制lib文件夹的时候。第一次把文件复制错了位置。从 /mnt/usr/lib 复制到了 /usr/lib/里。第二次执行到一半,发现在覆盖 libglib的时候,SSHFS废了。

庆幸自己第一次复制错了没有删除,为了安全起见我在VNC下完成了覆盖。

18:09

MySQL不知道因为什么原因无法启动,日志报错Could notcreate unix socket lock file /var/run/mysqld/mysql.sock.lock。

在尝试了各种方法之后,发现把socket的路径指向 /tmp 里面就可以了。

/tmp/var/run 都挂载在tmpfs下。我在复制的时候没有注意,覆盖了 /var/run

也就是说,重启可以解决问题。

18:11

网站成功上线!

截止至网站上线,两个工单还是没有人回复,之前换IP的申请也没有扣款。

虽然网上很多人表示Cloudcone的工单都是秒回,但这次的事件真的让我担心日后的使用。

就这样吧。

2019-2-9 20:34:19