Posts tagged with “中文”

Notes for upgrading Debian 7 to Debian 10 on an old cheap VPS

前言

好几年前 123systems.net 打折的时候买了这个vps,年付只要 $3.8。不过配置还说得过去,256M 内存,10G ssd硬盘,每个月有512G流量,而且是 KVM的。那时候我还不知道啥是docker,买这台vps的目标很单纯,就是翻墙。然而当时 123systems.net 的服务非常烂,网络差,北京连过去经常丢包不说,而且还常down机,你提个ticket也要过上好几天才有人搭理。便宜没好货....看在乞丐价的份上,所以大爷我也忍了。不就3块8么,全当喂狗了。(所以后面不久我又从另一家买了一台配置高点的)。后来听说 123systems 被另一家 vps 提供商(对,就是chicago vps)收购了,我想那服务是不是会好点,就又连上去试了下。别说,网络真的稳定多了!也几乎不down机了,于是它就作为我的一个备用翻墙节点用起来了。这也才有了后面的年年续费。

在这台机器上我用了好几年 Ubuntu 14.04,但这台 vps 能够安装的操作系统模板,这么多年就一直没更新过。Ubuntu 最高是14.04, Centos是 6.5, Debian是7.3,Fedora 是 20。后来我玩 Docker 的时候想到这台机器是 kvm 啊,可以装docker的。于是就在上面装了Docker。后来随着 Docker 的一直升级,渐渐地新版 Docker 就不再支持 Ubuntu 14.04了。虽然用旧版也不是不行,但是我动了升级操作系统的念头。虽然模板中只有 14.04, 我总可以自己升级装好的系统嘛。然而升级并不顺利,我曾经磕磕绊绊升到 16.04 用了几天,发现不稳定(经常无故自动关机)就又回到了 14.04。后来经过一个不眠之夜,我装上了 Debian 7 又费了好大劲升级到 Debian 8 jessie。这个还比较稳定,就一直用着,直到昨天晚上。

昨天晚上闲逛的时候,我发现有一个人写了个一键自动重灌vps操作系统的脚本,支持 Debian 和 Centos, 支持指定版本号。 我的心又活络起来了。虽然那篇文间是2018年的,已经挺老了,但我还是打定主意打算试试,万一支持 Debian 10 呢。于是该备份的备份,然后开始尝试。不过作者说了不保证谁都能用,也不保证不丢数据。悲伤的是 他说对了

Debian装上启动不了,Centos 看文章下面的评论最高只能升级到 6.10 而我的目标是 7.7。罢了罢了!此路不通!看看天色已晚,已过夜里12点。我打算再最后试一次, 装个 Fedora 20 看看能不能一路升到最新。然而也不顺利。都1点了,去他的,睡觉了。

心里有事,睡得也不踏实,于是今天早上早早就起来了。不想再用Ubuntu了,于是重新装上 Deiban 7, 我想这次,就升级到 Deiban 8 和过去一样算了,回到原点凑付用吧。一台年付才3.8的破机器,不值当我花这么多时间折腾。然而 Debian 7 的源已经都死掉了,所以 Deiban 7 的系统也没法更新了,直接升 8 就好了。然而升 8 也不顺利,上次升级的时候并没有记笔记,所以好多问题东西要重新搜索,重新找(所以我今天在写笔记!)。就在到处找的过程中,我看到一个人在某个问题下评论说,他从 Debian 7 一直升级到了 Debian10,虽然花了很多时间,但感觉 amazing! 那我也试试唄。

现在是中午12点,开心的是我也搞定了那个升级,并且正在趁热乎把中间找资料的坎坷记录下来。那么口水到此结束,下面干货开始:

正文

  1. Debian 7 更新 /etc/apt/sources.list 为
deb http://deb.debian.org/debian/ jessie main contrib non-free
deb-src http://deb.debian.org/debian/ jessie main contrib non-free

deb http://security.debian.org/ jessie/updates main contrib non-free
deb-src http://security.debian.org/ jessie/updates main contrib non-free

deb http://deb.debian.org/debian/ jessie-updates main contrib non-free
deb-src http://deb.debian.org/debian/ jessie-updates main contrib non-free
  1. 用 root
apt-get -y update
apt-get -y install apt -t jessie
apt -y upgrade
apt-get -y dist-upgrade 
reboot

当然升级之路不会这么顺利,你肯定会遇到 no public key available for the following key IDs: xxxxx 和什么源已过期无法验证之类的报错。对于前者, 使用 apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 1397BC53640DB551(请一定记着把key换成你那里看到的key);至于后者,可以用加参数大法apt-get -y -o Acquire::Check-Valid-Until=false update 解决。总起来说这一步还是蛮顺利的,升级完重新启动能直接进系统,网络什么都是好的。

  1. Jessie to Stretch,继续用root身份哦
sed -i 's/jessie/stretch/g' /etc/apt/sources.list
apt-get update
apt-get upgrade
apt-get dist-upgrade

应该说这个升级也蛮顺利的,除了升级完重启后....我就再也连接不上vps之外。还好有 Vnc 可以用,虽然网页上提供的 html5 vnc cient不能使,但我用本机的 vncviewer 能够连接上。 连上之后,发现除了网卡参数全丢了,其他都是正常的。那...网卡参数怎么设置?原来的参数都是啥?我不知道哇。于是又一通搜索,各种尝试,还是不行。最后想起 vps 控制台有 Reconfigure Networking 的功能,那就死马当活马医,试试吧。一试,好了!那么.....从7升到9已经是挺了不起的成就了,还升10么?升!

  1. Stretch to Buster,继续用 root 身份
sed -i 's/stretch/buster/g' /etc/apt/sources.list
apt-get update
apt-get upgrade
apt-get full-upgrade

这个升级也蛮顺利的,然而升级完重启后就连接不上vps的问题再一次发生了。根据刚才的经验用了 vps 控制台的 Reconfigure Networking 的功能,但这次没有那么走运,网还是不通。经过一番排查之后,发现这次系统注入参数时使用的网卡名字是 eth0,而我记得以前网卡的名字是 ens3。于是修改 /etc/network/interfaces 文件,把 eth0 改为 ens3 然后 systemctl start networking.service。成功!

每一次折腾,都能学到点什么,技术就是这么一点点折腾来的。但是如果不记录下来,下次再找又要花很多时间。所以...我又花了40分钟写这篇blog。不过还是很开心啊!把看似不可能事情最终搞成了,就是那样的开心!

参考资料: debian-wheezy-update-repository
参考资料: how-to-upgrade-debian-7-wheezy-to-10-buster-safely
参考资料: how-to-upgrade-debian-8-jessie-to-debian-9-stretch

麻雀

这些天受疫情影响,我只能在家工作。我的工作台的右侧,就是正门门前的那块空地。平常我们都是使用后院的门,正门极少使用。这块空地就成了麻雀经常光顾的地方。

而我呢,工作累了,或者想偷懒的时候,往右一瞥往往就会看到它们或者在玩,或者在吃东西。虽然并没有人惊吓它们,但我却感到它们不像新西兰别的鸟。那些鸟大多大大咧咧的不怎么怕人,甚至懒得飞,即使你驱赶它们,它们也经常用快跑代替飞。麻雀总是警觉的,不论是吃还是玩,都是玩一秒钟或者吃两秒钟,就赶紧四顾看看有没有危险。我从没有看到过它放松的时刻。

这么警觉的动物会活得很长吧,并不。日日过着担惊受怕的生活,怎么可能长寿呢。查了一下,果然。普通麻雀在野外的寿命也就三年。

可爱又可怜的小精灵啊。

夏时制即将结束所思所想

这是我对看新西兰站长所发文章「4月5日星期天凌晨3点新西兰夏令时结束」的评论。

这意味着对那些不记录 unix 时间戳而只记录本地时间的系统,如果他们依赖时间排序(因为没有时间戳)的话,夜里2点-3点钟的记录会是紊乱的,因为这段时间会过两遍。显示上看起来没有问题的数据,其实是偏离真实顺序的。比如一篇文章的两个评论,明明是后面的评论回复前面的评论,即可能现回复的评论先显示,然后才显示被回复的评论这种“怪事”。当然了,如果用unix时间戳排序会有另一种问题,数据的顺序是正确的,但显示的本地时间却是紊乱的。可能出现显示一个人在 2:45 分发表了一篇评论,但另一个人却“使用了月光宝盒”回到 2:15 分回复 2:45 分评论的“怪事”。

站长说的对,人们应该调整自己的作息时间,而不是调快或调慢计划仪器。但站长说的又是错的,因为人是愚蠢的动物,自律的人是那么的少,如果依赖们自己调整作息时间,节能效果就会大打折扣。所以“调快调慢”计时设备这个看上去错误的解决方案,即又是最管用的方案。世界就是这么奇妙!

观影老电影《牧马人》

今晚一家人一起看了个老电影。那个年代的电影,意识形态的东西自然是少不了的。不过我的看点在那些东西之外。如果我是剧中的主角许灵均,我会随亿万富翁的父亲远走高飞吗?不好说。

电影除了讲故事,也无意间充当了那个年代风俗人情的不精确的记录员。精确的记录不好看,不精确不是bug,是feature,哈哈。这也是我喜欢看老电影的原因之一。

要说剧中哪个人物我最喜欢,当然是这个影片中的女主角啦,漂亮又大方,勤劳能干,还学习上进,完美的不像真的。

与Eric一起看电影

客户端 POST 错误,服务端应该回 200 还是 400?

刚好今天和一个同事在这个问题上意见不一。

于是翻到了知乎上的这个问题,遗憾的是下面的答案都很水,没有一个深得我心。这很有可能证明我的看法是片面的,管它呢。但它激起了我的表达欲望,我于是键盘侠了下面这一篇。刚好傻子知乎嫌弃我没有认证国内手机号,不让我发表。那我就给自己的 Blog 添块砖吧。

其实这个标题蛮误导人。Post 错误....这种表述再宽泛了。因此有人支持有人反对都不奇怪。多么 Bad 的 Request 算Post错误?每个人有每个人的出发点,这太难达成一致了。

我的观点缩成一句话,只要请求使用 Api 协议(参数个数类型都)正确,我接受甚至有点喜欢响应 200 OK 再给出具体的 ErrorCode 和 ErrorMessage 这种做法。 既然请求能抵达你的 Action 处理方法,至少说明发起请求的一方是有一点点诚意的。如果你再有一点点时间,即使请求不是十全十美,给个不等于0的ErrorCode和一个合理的ErrorMessage是一种绅士的做法。

如果请求格式合法,服务器能够理解,但不能给出满意的结果,或者说 errorCode 不是0的情况,我个人的实践的是返回 200,并给出具体的错误码和错误信息。理由是这个请求不是无效的和非法的,直接扔400 是给前端增加工作量。

即使现在在的框架已经内置了 NotFound() 之类的快捷响应办法, 但只要Route正确到达了我的处理方法,而我又不想偷懒,我的观点也是应尽量给出人类能够理解的出错信息。你总不能因为商品暂时缺货就直接甩404吧!

我不赞成甚至讨厌那些把2xx - 5xx那几十个code 一个个或合理或牵强附会的对号入座,毕竟发明大部分这些Code 的时候还根本没有 Restful 概念。它们都过于宽泛了,是给喜欢偷懒和甩锅的程序员们准备的。即使你使用的前端框架能够自动帮你处理这些code,广泛而大量的使用这些code也只会降低用户的体验而不是改善用户的体验。因为最终用户大部分时候都只能知道错了,但不知道错在哪里。

当然是很个人的看法,欢迎任意批判。