解决 CentOS 7 报错: /var/run/yum.pid 已被锁定

报错描述

今天在使 yum 命令安装软件的时候遇到了如下报错:

/var/run/yum.pid 已被锁定,PID 为 3355 的另一个程序正在运行。
Another app is currently holding the yum lock; waiting for it to exit...
  另一个应用程序是:PackageKit
    内存:155 M RSS (717 MB VSZ)
    已启动: Sun Apr 28 15:01:12 2019 - 04:40之前
    状态  :运行中,进程ID:3355

报错截图如下:

图 1
图 1

解决方案

运行下面的命令, 强制结束 yum 进程即可:

rm -f /var/run/yum.pid

另外, 如果担心强制删除系统文件会引发难以预测的错误, 也可以尝试稍等一会(经过实测发现, 稍微等待一段时间后上述报错可能会自行消失)或者选择重启系统.

解决 CentOS 7 报错: “Repository base is listed more than once in the configuration”和”没有可用软件包 XXX”的问题

报错描述

我的 CentOS 7 的更新源使用的是直接从 163 镜像站上下载的更新源文件.

今天在使用 yum makecache 命令从更新服务器上把软件包的信息下载到本地缓存起来时遇到了如下报错:

Repository base is listed more than once in the configuration
Repository updates is listed more than once in the configuration
Repository extras is listed more than once in the configuration
Repository centosplus is listed more than once in the configuration

报错截图如下:

图 1
图 1

而且在我使用 yum install htop 命令安装 htop 的时候, 还提示:

没有可用软件包 htop。
错误:无须任何处理

但是, 正常情况下 CentOS 7 的源里面应该是有 htop 这个软件包的, 可以直接使用 yum install htop 成功安装(我之前安装过).

上述问题的相关截图如下:

图 2

解决方案

分析上面的报错, 主要还是软件源文件出了问题, 于是我们先进入软件源配置文件所在的目录下:

cd /etc/yum.repos.d/

ls 查看一下, 回显如下:

[root@localhost yum.repos.d]# ls
CentOS7-Base-163.repo    CentOS-CR.repo         CentOS-Media.repo
CentOS-Base.repo         CentOS-Debuginfo.repo  CentOS-Sources.repo
CentOS-Base.repo.backup  CentOS-fasttrack.repo  CentOS-Vault.repo
[root@localhost yum.repos.d]#

从对报错内容的分析来看, 应该是软件源有重复(“listed more than once”), 所以这里我们尝试删除一些上面的软件源配置文件.
在删除之前, 先对 /etc/yum.repos.d/ 目录下的文件做一个整体的备份, 以便于尝试失败后的还原, 操作过程如下:
/etc/yum.repos.d/ 目录下的文件整体压缩成一个 .zip 文件:

zip centos7-repo.zip /etc/yum.repos.d/*

然后执行删除操作:

rm -rf CentOS-CR.repo CentOS-Debuginfo.repo CentOS-fasttrack.repo CentOS-Media.repo CentOS-Sources.repo CentOS-Vault.repo

之后把 CentOS7-Base-163.repo 中的内容复制进 CentOS-Base.repo:

cp -p CentOS7-Base-163.repo CentOS-Base.repo

最后删除 CentOS7-Base-163.repo:

rm -rf CentOS7-Base-163.repo

之后运行如下命令重建缓存, 没有再出现”Repository base is listed more than once in the configuration”的报错:

yum clean all
yum makecache

但是, 在我尝试使用 yum 命令安装软件时, 仍然遇到了”没有可用软件包 XXX”的报错, 如下:

[root@localhost yum.repos.d]# yum install htop
已加载插件:fastestmirror, langpacks
Loading mirror speeds from cached hostfile
没有可用软件包 htop。
错误:无须任何处理

“没有可用软件包”说明在 YUM 源中没有对应的软件包(163 的源本身应该是没有问题的, 这是一个大家都常使用的 Linux 方面的国内软件源).
其实, 在 CentOS 和 RHEL 等操作系统中, 常使用的软件源不仅有 YUM, 还有 EPEL. EPEL 英文全称为:”Extra Packages for Enterprise Linux”. 直译为中文就是”用于企业 Linux 的额外软件包”. EPEL 是 Fedora 的一个项目, 有关该项目的官方说明可以在下面的链接中找到:

EPEL – Fedora Project Wiki

这里我摘录一段 Fedora 对 EPEL 项目的说明:

企业版 Linux 附加软件包(以下简称 EPEL)是一个 Fedora 特别兴趣小组,用以创建、维护以及管理针对企业版 Linux 的一个高质量附加软件包集,面向的对象包括但不限于 红帽企业版 Linux (RHEL)、 CentOS、Scientific Linux (SL)、Oracle Linux (OL) 。

EPEL 的软件包通常不会与企业版 Linux 官方源中的软件包发生冲突,或者互相替换文件。EPEL 项目与 Fedora 基本一致,包含完整的构建系统、升级管理器、镜像管理器等等。

https://fedoraproject.org/wiki/EPEL/zh-cn

在 CentOS 7 中安装 EPEL 源的命令如下:

yum install -y epel-release

安装完成后, 在 /etc/yum.repos.d 目录下会多出来下面两个文件, 这两个文件就是 EPEL 源的配置文件:

  • epel.repo
  • epel-testing.repo

查看 epel.repo 文件中的内容可以发现其中软件源的地址指向的是 https://mirrors.fedoraproject.org/, epel-testing.repo 这个文件中的软件源的地址也是指向的是 https://mirrors.fedoraproject.org/. 为了加快软件安装速度, 我们可以将其更改为国内的 EPEL 源, 操作步骤如下:

进入 /etc/yum.repos.d 目录, 下载阿里云 EPEL 源:

wget http://mirrors.aliyun.com/repo/epel-7.repo

备份 Fedora 官方提供的 EPEL 源配置文件:

cp -p epel.repo epel.repo.bak
cp -p epel-testing.repo epel-testing.repo.bak

删除 epel-testing.repo:

rm -rf epel-testing.repo

epel-7.repo 中的内容覆盖写入到原来的 epel.repo 文件中:

cp -p epel-7.repo epel.repo

删除 epel-7.repo 文件:

rm -rf epel-7.repo

重新生成缓存:

yum clean all
yum makecache

之后可以正常安装软件.

总结

遇到”Repository base is listed more than once in the configuration”的问题要考虑系统中是否存在重复的软件源, 遇到”没有可用软件包 XXX”的问题首先要确认要安装的软件包名称是否写对了, 例如安装 pip 的命令不是 yum install pip, 而是 yum install python-pip, 在此之后如果问题仍然存在就需要考虑当前系统中是否正确配置了 YUM 和 EPEL 两个软件源.

百度浏览器宣布 PC 端部分功能停止服务

百度浏览器于 2019 年 04 月 03 日发布公告称将于 2019 年 04 月 30 日对产品部分功能停止服务, 停止服务的产品包括桌面百度, 百度工具栏, 百度地址栏, 百度极速浏览器和 hao123 浏览器. 这些停止服务的产品将不再更新.

公告全文如下:

【公告】百度浏览器(PC)部分功能停止服务

尊敬的用户:
您好,由于部门业务调整,官方将于2019年04月30日对产品部分功能停止服务。相关的产品包括桌面百度、百度工具栏、百度地址栏、百度极速浏览器,hao123浏览器,产品将不再更新,基本功能本地仍可使用。相关事宜公告如下:
1、用户登录功能,已登录用户登录状态失效,但仍可本地保留用户基本信息(收藏夹、历史纪录、设置等),未登录用户将不提供服务;
2、积分商城将无法访问,不提供用户积分查询服务;
3、用户的设置信息、历史纪录、收藏夹云同步失效;
4、产品相关推荐内容消失,相关页面将不能访问,如:新建标签(newtab.baidu.com)、主页(0.baidu.com);
5、一切插件相关功能均不可用,已经安装插件的可能部分能够继续使用;
6、皮肤相关将保留简单样式,其它不可用;
由此带来的不便敬请谅解。感谢您的理解与支持!我们衷心期待您的继续支持和关注百度旗下更多优秀的产品!

2019年04月03日

来自: https://gss0.bdstatic.com/5bVWsj_p_tVS5dKfpU_Y_D3/res/notice_llq.html

公告截图如下:

图 1 百度浏览器(PC)部分功能停止服务的公告
图 1 百度浏览器(PC)部分功能停止服务的公告

目前输入百度浏览器的官网地址”https://liulanqi.baidu.com/”会跳转到”https://gss0.bdstatic.com/5bVWsj_p_tVS5dKfpU_Y_D3/res/notice_llq.html”并显示上述关于百度浏览器停止服务的公告.

“https://liulanqi.baidu.com/”到”https://gss0.bdstatic.com/5bVWsj_p_tVS5dKfpU_Y_D3/res/notice_llq.html”的跳转过程是使用 302 暂时性转移重定向实现的, 如图 2:

图 2 302 暂时重定向
图 2 302 暂时重定向

“gss0.bdstatic.com”是百度 CDN 的一个节点域名, 备案号为”京ICP证030173号-23”.

Ubuntu 19.04 国内更新源

2019年4月18日, Ubuntu 19.04 正式发布. Ubuntu 19.04 的 Codename 是”disco(迪斯科舞厅)”:

zkf@ubuntu:~$ lsb_release -c
Codename:    disco

为了方便国内用户使用最新版的 Ubuntu 19.04, 本文提供了 Ubuntu 19.04 的国内更新源以及更改更新源的完整步骤.

进入更新源文件所在目录:

cd /etc/apt/

备份原有更新源文件:

sudo cp -p sources.list sources.list.bak

编辑更新源文件:

sudo vi sources.list

写入如下国内更新源:

#阿里云源
deb http://mirrors.aliyun.com/ubuntu/ disco main restricted universe multiverse
deb-src http://mirrors.aliyun.com/ubuntu/ disco main restricted universe multiverse
deb http://mirrors.aliyun.com/ubuntu/ disco-security main restricted universe multiverse
deb-src http://mirrors.aliyun.com/ubuntu/ disco-security main restricted universe multiverse
deb http://mirrors.aliyun.com/ubuntu/ disco-updates main restricted universe multiverse
deb-src http://mirrors.aliyun.com/ubuntu/ disco-updates main restricted universe multiverse
deb http://mirrors.aliyun.com/ubuntu/ disco-backports main restricted universe multiverse
deb-src http://mirrors.aliyun.com/ubuntu/ disco-backports main restricted universe multiverse
deb http://mirrors.aliyun.com/ubuntu/ disco-proposed main restricted universe multiverse
deb-src http://mirrors.aliyun.com/ubuntu/ disco-proposed main restricted universe multiverse

#中科大源
deb https://mirrors.ustc.edu.cn/ubuntu/ disco main restricted universe multiverse
deb-src https://mirrors.ustc.edu.cn/ubuntu/ disco main restricted universe multiverse
deb https://mirrors.ustc.edu.cn/ubuntu/ disco-updates main restricted universe multiverse
deb-src https://mirrors.ustc.edu.cn/ubuntu/ disco-updates main restricted universe multiverse
deb https://mirrors.ustc.edu.cn/ubuntu/ disco-backports main restricted universe multiverse
deb-src https://mirrors.ustc.edu.cn/ubuntu/ disco-backports main restricted universe multiverse
deb https://mirrors.ustc.edu.cn/ubuntu/ disco-security main restricted universe multiverse
deb-src https://mirrors.ustc.edu.cn/ubuntu/ disco-security main restricted universe multiverse
deb https://mirrors.ustc.edu.cn/ubuntu/ disco-proposed main restricted universe multiverse
deb-src https://mirrors.ustc.edu.cn/ubuntu/ disco-proposed main restricted universe multiverse

#163源
deb http://mirrors.163.com/ubuntu/ disco main restricted universe multiverse
deb http://mirrors.163.com/ubuntu/ disco-security main restricted universe multiverse
deb http://mirrors.163.com/ubuntu/ disco-updates main restricted universe multiverse
deb http://mirrors.163.com/ubuntu/ disco-proposed main restricted universe multiverse
deb http://mirrors.163.com/ubuntu/ disco-backports main restricted universe multiverse
deb-src http://mirrors.163.com/ubuntu/ disco main restricted universe multiverse
deb-src http://mirrors.163.com/ubuntu/ disco-security main restricted universe multiverse
deb-src http://mirrors.163.com/ubuntu/ disco-updates main restricted universe multiverse
deb-src http://mirrors.163.com/ubuntu/ disco-proposed main restricted universe multiverse
deb-src http://mirrors.163.com/ubuntu/ disco-backports main restricted universe multiverse

#清华源
deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ disco main restricted universe multiverse
deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ disco main restricted universe multiverse
deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ disco-updates main restricted universe multiverse
deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ disco-updates main restricted universe multiverse
deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ disco-backports main restricted universe multiverse
deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ disco-backports main restricted universe multiverse
deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ disco-security main restricted universe multiverse
deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ disco-security main restricted universe multiverse
deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ disco-proposed main restricted universe multiverse
deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ disco-proposed main restricted universe multiverse

更新系统:

sudo apt-get update
sudo apt-get upgrade

拟定每年的 4 月 18 日为本站的”数据安全日”

就在刚刚过去的 4 月 18 日的下午, 我在使用 “tar” 命令对网站的文件进行打包备份时, 由于将 “tar” 命令后面的参数写反了, 导致网站文件发生错误, Web 服务器也发生故障, 进而使本站无法访问. 由于我在故障发生之前备份了数据库, 再加上本站大部分图片都存储在独立的图片服务器中, 因此我才得以在 4 月 19 日的下午将网站恢复并上线.

这次网站事故使我深刻意识到数据安全的重要性, 如果我没有数据库的备份文件, 那么很可能导致我投入很多精力维护的这个网站就此消失, 因此, 我计划将每年的 4 月 18 日定为本站的 “数据安全日”, 即惊醒自己, 也希望大家都能更加重视数据安全.

另外, 关于本次网站事故的发生过程与我的处理过程, 我会在之后写一篇博文详细回顾.

巴黎圣母院大火:世界文明的又一次劫难

法国当地时间 4 月 16 日(周一),位于巴黎市中心的巴黎圣母院发生火灾。根据有关报道,本次火灾造成巴黎圣母院三分二的塔顶被毁,但好在整体结构得以保存。

图 1 火焰笼罩中的巴黎圣母院,From LeLaisserPasserA38, https://zh.wikipedia.org/wiki/File:Incendie_Notre_Dame_de_Paris.jpg, 本文件采用知识共享署名-相同方式共享 4.0 国际许可协议授权。
图 1 火焰笼罩中的巴黎圣母院,From LeLaisserPasserA38, https://zh.wikipedia.org/wiki/File:Incendie_Notre_Dame_de_Paris.jpg, 本文件采用知识共享署名-相同方式共享 4.0 国际许可协议授权。

发生本次火灾之前的巴黎圣母院:

图 2 由Sanchezn - 自己的作品,CC BY-SA 3.0,https://commons.wikimedia.org/w/index.php?curid=3011138
图 2 由Sanchezn – 自己的作品,CC BY-SA 3.0,https://commons.wikimedia.org/w/index.php?curid=3011138

巴黎圣母院大约建造于 1163 年到 1250 年期间,全名为“巴黎圣母主教座堂 (Cathédrale Notre-Dame de Paris)”是一座哥特式建筑。
巴黎圣母院既是一座教堂,也是一个艺术品,例如在本次大火中被烧毁的尖塔和玫瑰花窗 (2019 年 4 月 17 日下午 16 时 10 分更新:据报道,法国官方确认三面玫瑰花窗均安全) 都具有极高的艺术价值。

巴黎圣母院的玫瑰花窗:

图 3 由Julie Anne Workman - 自己的作品,CC BY-SA 3.0,https://commons.wikimedia.org/w/index.php?curid=11590000
图 3 由Julie Anne Workman – 自己的作品,CC BY-SA 3.0,https://commons.wikimedia.org/w/index.php?curid=11590000

從蒙帕納斯大樓遠眺巴黎聖母院:

图 4 由Julie Anne Workman - 自己的作品,CC BY-SA 3.0,https://commons.wikimedia.org/w/index.php?curid=11590000
图 4 由Julie Anne Workman – 自己的作品,CC BY-SA 3.0,https://commons.wikimedia.org/w/index.php?curid=11590000

大火发生时,许多民众在塞纳河畔忍不住哭泣,还有人跪地祈祷。火灾发生当晚,一些人向着巴黎圣母院的方向合唱圣歌,寄托心中的悲痛。虽然巴黎圣母院不在中国,但是这种看着本国和本民族文明象征的珍宝被毁时的切肤之痛,中国人是有同感的。
巴黎圣母院还可以修缮重建,也许再过八百年之后,巴黎圣母院仍然是一座恢弘壮丽的建筑,继续向全世界慕名而来的游客讲述着法兰西文明的多姿多彩,但是,我们的圆明园却被永远地禁锢在一片废墟之中,千千万万生长在这片土地上的中国人再也没有可能去一睹这座园林的雄伟壮阔。是的,圆明园之所以被烧的一部分原因是当时的中国软弱无能,“落后就要挨打”是弱肉强食的历史铁律——直到今天仍然如此。
不过,我并不认同一部分人因为英法联军曾经火烧圆明园而对如今法国的遭遇落井下石,说这是“天道轮回”。
我们不能以一部分人在一段时间内的罪行作为衡量一个国家或民族的所有人在整个历史长河中的善恶。艺术和科学一样都是没有国界的,巴黎圣母院不仅仅是法国人的,也是全世界的,作为人类的一份子,我也不希望看到如同巴黎圣母院这样的人类文明的宝贵财富在烈火中毁于一旦,正如我同样不希望圆明园在烈火中毁于一旦一样。
中国的圆明园,法国的巴黎圣母院以及世界上其他国家和地区的珍贵文物都是人类先民的智慧结晶,代表着一个国家和民族的历史,也代表着人类文明。希望在未来,这样的文明劫难能够不再发生,无论是人类之间还是人类与人类文明之间,都需要相互爱护与包容。

圆明园大水法残迹:

图 5 来自颐园新居,https://zh.wikipedia.org/wiki/File:Yuanmingyuan_Ruins_of_Dashuifa_20120715.JPG, 本文件采用知识共享署名-相同方式共享 3.0 未本地化版本许可协议授权。
图 5 来自颐园新居,https://zh.wikipedia.org/wiki/File:Yuanmingyuan_Ruins_of_Dashuifa_20120715.JPG, 本文件采用知识共享署名-相同方式共享 3.0 未本地化版本许可协议授权。

圆明园海晏堂遗址正面喷水池(十二生肖人身兽首像所在地):

图 6 来自颐园新居,https://zh.wikipedia.org/wiki/File:Yuanmingyuan_Haiyantang_20130126.JPG, 本文件采用知识共享署名-相同方式共享 3.0 未本地化版本许可协议授权。
图 6 来自颐园新居,https://zh.wikipedia.org/wiki/File:Yuanmingyuan_Haiyantang_20130126.JPG, 本文件采用知识共享署名-相同方式共享 3.0 未本地化版本许可协议授权。图 6 来自颐园新居,https://zh.wikipedia.org/wiki/File:Yuanmingyuan_Haiyantang_20130126.JPG, 本文件采用知识共享署名-相同方式共享 3.0 未本地化版本许可协议授权。

降低 Kali Linux 资源占用:配置使用 Xfce 4 桌面环境

前言

Xfce Desktop Environment website:
https://www.xfce.org/

Xfce-维基百科:
https://zh.wikipedia.org/wiki/Xfce

Xfce 不是最华丽的 Linux 桌面环境,但却是相当节省系统资源的 Linux 桌面环境。就我个人的使用习惯而言,在 Linux 上,特别是 Linux 虚拟机中使用 Xfce 桌面是一个极佳的选择,因为这样可以把有限的系统资源更多地用于处理生产性作业。
Xfce 最新的版本是 “4.12”.
Kali Linux 2019.1 以及该版本之前的一些版本使用的都是 Gnome 桌面环境而不是 Xfce, 因此,本文就从降低系统资源占用的角度出发,介绍一下将 Kali 的桌面环境从 Gnome 更换到 Xfce 4 的过程。

过程

安装 Xfce 4,命令:

apt install kali-defaults kali-root-login desktop-base xfce4 xfce4-places-plugin xfce4-goodies

在安装的过程中(可能)会要求我们选择提供图形化系统登录界面的图形管理程序(A display manage is a program that provides graphical login for the X Windows System.),只有一个显示管理器可以管理给定的 X server (X server 是用于管理图形化界面的服务器端程序),但是如果当前系统中安装了多个显示管理器包,就需要选择一个默认的显示管理器(Only one display manage can manage a given X server, but multiple display manager packages are installed. Please select which display manager should run by default.),这里我选择的默认显示管理器是 “gdm3”, 如图 1:

图 1
图 1

切换桌面:

update-alternatives --config x-session-manager

回显如下:

root@kali:~# update-alternatives --config x-session-manager
There are 3 choices for the alternative x-session-manager (providing /usr/bin/x-session-manager).

  Selection    Path                    Priority   Status
------------------------------------------------------------
* 0            /usr/bin/gnome-session   50        auto mode
  1            /usr/bin/gnome-session   50        manual mode
  2            /usr/bin/startxfce4      50        manual mode
  3            /usr/bin/xfce4-session   40        manual mode

Press <enter> to keep the current choice[*], or type selection number:

输入 3 以启动 Xfce4,回显如下:

root@kali:~# update-alternatives --config x-session-manager
There are 3 choices for the alternative x-session-manager (providing /usr/bin/x-session-manager).

  Selection    Path                    Priority   Status
------------------------------------------------------------
* 0            /usr/bin/gnome-session   50        auto mode
  1            /usr/bin/gnome-session   50        manual mode
  2            /usr/bin/startxfce4      50        manual mode
  3            /usr/bin/xfce4-session   40        manual mode

Press <enter> to keep the current choice[*], or type selection number: 3
update-alternatives: using /usr/bin/xfce4-session to provide /usr/bin/x-session-manager (x-session-manager) in manual mode

卸载 Gnome 桌面环境:

apt remove gnome-core
apt remove gnome-shell

重启系统:

reboot

重新登录系统之后可以看到已经成功地将 Kali Linux 的桌面环境更换为 Xfce 4,如图 2:

图 2
图 2

探秘维基解密网站的服务器和域名

2019 年 04 月 11 日,维基解密的创始人朱利安·阿桑奇因为失去了厄瓜多尔政府的政治庇护,在位于伦敦的厄瓜多尔驻英国大使馆中被英国警方逮捕。

图 1 由David G Silvers. – https://www.flickr.com/photos/dgcomsoc/14770416197/,CC BY-SA 2.0,https://commons.wikimedia.org/w/index.php?curid=34813282

维基解密网站成立于 2006 年 12 月,至今该网站仍然在运作并可以通过国际互联网访问。

图 2 维基解密网站(https://wikileaks.org/)首页截图
图 3 维基解密网站(https://wikileaks.org/) LOGO

于是我就在想,维基解密使用的服务器在哪里?域名如何解析的?

带着这些疑问,我使用一台位于国外的 VPS, Ping 了一下 “wikileaks.org” 这个域名,测试结果如下:

图 4

由图 4 可知,解析到的 “wikileaks.org” 这个域名所在的服务器的 IP 地址是 ”195.35.109.53”.

随后,我在 Ipinfo(https://ipinfo.io/) 这个网站查询了 “195.35.109.53” 这个 IP 的信息(https://ipinfo.io/195.35.109.53),查询结果如图:

图 5

根据查询结果显示, “195.35.109.53” 这个 IP 地址的托管机构是位于挪威奥斯陆的 Blix Solutions AS.

Blix Solutions AS 的官网首页如图:

图 6

在 “dnslytics.com” 上查询 “wikileaks.org” 可以获得如下信息(https://dnslytics.com/domain/wikileaks.org):

域名 “wikileaks.org” 的基础信息:

图 7

Whois 信息:

图 8

NS 记录:

图 9

MX 记录:

图 10

在 dnslytics.com 上查询 IP 地址 “195.35.109.53” 可以看到(https://dnslytics.com/ip/195.35.109.53), 该 IP 地址和域名 “wikileaks.org” 之间的 DNS 解析服务由 “host1.no” 提供,HOST1 是一家位于挪威奥斯陆的网络公司,提供虚拟主机,云服务器和域名购买服务等,其官网首页如图:

图 11

此外,我们在 dnslytics.com 提供的查询结果中还可以看到,有 6 个域名都解析到了IP 地址为 “195.35.109.53” 的这台服务器上,这些域名应该都是属于维基解密的。

图 12

在中文维基百科中可以找到如下关于维基解密网站所使用的主机和域名的信息:

主机

维基解密形容自己为“一个对大量来源不明的泄密文件进行审查的系统”。该网址可被多个服务器使用且不同的域名伴随着大量的阻断服务攻击,同时它的切断服务来自不同的域名解析系统提供者。

直到2010年8月,维基解密一直使用PRQ的主机,一个提供“高度安全性,零故障的主机服务”的瑞典公司。据说PRQ公司“几乎没有关于其客户的信息,很少进行维护”。维基解密网站托管在以坚持客户匿名著称的瑞典网络服务提供商PRQ.se,这家公司可以承受法律压力和网络攻击。先将文件送到位于比利时的服务器上,再送到位于“另一个法律上较友善的国家”的服务器上,然后这些文件被转存到其他地方后删除,。由一批匿名的工程师提供技术维护,整个流程和提交的文件都被加密,并使用经过修改的Tor网络匿名传输,整个系统即使核心成员也无法全部进入。此外,维基解密还在系统中一直传递许多虚假的提交文件,以使真正的文件难以被发现。

现在,维基解密的主机主要由建在一座核掩体中的Bahnhof公司提供。其他服务器以瑞典服务器为中心分布于全世界。阿桑奇曾说服务器设置在瑞典(及其他国家)“主要是因为这些国家能为这个网站的泄密行为提供法律保护”。他认为瑞典宪法给予了那些信息提供者完全的法律保护。在瑞典,政府对任何类型的报纸的消息来源的问询都是被禁止的。这些法律,以及PRQ的主机,让任何一个政府迫使维基解密下线的行动都变得困难,它们设置了一个能抵御来自任何牢骚者的诉讼的保护伞,保护了维基解密的自由。维基解密在秘密地点维护他们的服务器、删除服务器日志并使用军事级别的加密技术来保护信息源和其它机要信息。”该种服务器组织形式被称为“防弹主机”。

2010年8月17日,一则消息被宣布,瑞典海盗湾将提供并管理多台维基解密的新服务器。海盗湾捐赠了免费的服务器和宽带给维基解密。该机构技术员将保证这些服务器的维护和工作。

在这个放置在旧服务器上的地址变成一个黑客拒绝式服务攻击的目标后,维基解密把其地址移到了亚马逊的服务器上。然而随后不久,该网址在亚马逊服务器上被“废止”。在一份公开声明中,亚马逊说维基解密未遵守它的服务条款。公司进一步解释说,“它们违反了条款的几个部分。比如,我们的服务条款声明‘你显示或授权显示的内容,不能用于支持违法或者可能导致某人或法律实体受到伤害的行为。’显然,维基解密显示了这种内容。”之后维基解密决定安装由法国OVH公司提供的属于维基解密自己的服务器。在受到来自法国政府的批评人士的刁难后,该公司转于寻求两个法院进行针对为维基解密提供服务器案的裁决。当里尔的法院迅速倾向于迫使OVH关闭维基解密网站时,巴黎法院声明他们需要更多的时间来研究高技术议题。

维基解密建立在几个软件包的基础上,包括Tor, PGP, MediaWiki以及Freenet。维基解密积极鼓励通过Tor发送信息,因为它能满足用户强烈的保密需求。

2010年11月4日,阿桑奇告诉瑞士电视台TSR他急需在中立的瑞士寻求政治庇护并建立一个维基解密基金以把各种工作移到这里。按阿桑奇所言,瑞士和冰岛是仅有的几个能让维基解密感到可以安全地工作的国家。

域名服务器

维基解密曾经使用EveryDNS的域名解析服务,该域名服务器曾受到DDoS攻击。攻击影响了EveryDNS的服务质量,故而该公司撤除了对维基解密的服务。资深的维基解密支持者通过一次DDoS攻击报复了EveryDNS。此外,由于博客中的错误,一些支持者误将EasyDNS当做EveryDNS,随后数量可观的支持者参与了对EasyDNS的抵制,最终迫使EasyDNS决定提供域名解析服务给维基解密。

https://zh.wikipedia.org/wiki/維基解密

根据上面的信息,维基解密曾使用过 PRQ 公司提供的主机服务,我搜索了一下,确实存在一个使用了 “PRQ.se” 域名并且经营主机服务的公司,其官网首页如图:

图 13

今天的探秘就到这里了。说是“探秘”其实也不准确,因为上面这些信息都是公开的,不过我之前确实不知道这些信息,所以我了解了一些之后就把我查到的资料放在这里与大家分享一下,满足一下小小的好(偷)奇(窥)心(欲)。

C / C++ 中的计时函数: clock()

clock() 函数是 C 标准库 time.h 中的一个函数, time.h 标准库中定义了各种涉及日期和时间的函数, 变量类型和宏. 其中, clock() 函数可以返回自程序开始执行到当前位置为止, 处理器走过的时钟打点数(即”ticks”, 可以理解为”处理器时间”). 在 VC++6.0 中, 每过千分之一秒(即 1 毫秒)则 clock() 函数的返回值加 1. 但是, 处理器的时钟打点数并不是一个人类可以直观感知的时间概念, 时钟打点数只描绘了该处理器在处理该问题时所耗费的”处理器时间”. 为了能将获取到的时间转换成便于人类理解且具有普遍性的”时 分 秒”的计时方式, 我们需要引入一个常量, 在 VC++6.0 中, 使用常量 CLOCKS_PER_SEC 来进行转换且 CLOCKS_PER_SEC=1000.
但是在不同的编译环境中, CLOCKS_PER_SEC 的数值可能是不同的. 在 Windows 10 中使用”Everything”这个程序在本机上搜索 stdio.h 可以看到我的这个计算机操作系统中存在”Emacs”, “CodeBlocks”和”Dev-cpp”三款编译器, 因此也就存在三套相互独立的 C 语言编译环境, 如图 1:

图 1

(下面以 Windows 10 下的 CodeBlocks 的编译环境为例, 查看在 C 语言的头文件中关于 CLOCKS_PER_SEC 的定义.)

在我的电脑上, CodeBlocks 的 C 语言头文件位于下面的位置:

C:\GreenSoftware\codeblocks-17.12mingw-nosetup\MinGW\include

在这个目录下找到 time.h 这个头文件, 可以在其中找到如下关于 CLOCKS_PER_SEC 的定义:

/*
 * Number of clock ticks per second. A clock tick is the unit by which
 * processor time is measured and is returned by 'clock'.
 */
#define    CLOCKS_PER_SEC  ((clock_t)1000)
#define    CLK_TCK     CLOCKS_PER_SEC

由上面的头文件中的定义可以知道, 常量 CLOCKS_PER_SEC 的值被定义为 1000, 变量类型为 clock_t.

为了验证, 我们可以在 Windows 平台上的 CodeBlocks 中运行如下 C++ 程序:

#include <iostream>
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
using namespace std;

int main()
{
    int i=10;
    clock_t start,finish;
    double Times, Times1;
    start=clock();
    while(i--){
        cout<<i<<endl;
    };
    finish=clock();
    Times=(double)(finish-start)/CLOCKS_PER_SEC;
    Times1=(double)(finish-start)/CLK_TCK;
    cout<<"start(时钟打点): "<<start<<endl;
    cout<<"finish(时钟打点): "<<finish<<endl;
    cout<<"CLOCKS_PER_SEC: "<<CLOCKS_PER_SEC<<endl;
    cout<<"CLK_TCK: "<<CLK_TCK<<endl;
    cout<<"运行时间(秒)(CLOCKS_PER_SEC): "<<Times<<endl;
    cout<<"运行时间(秒)(CLK_TCK): "<<Times1<<endl;

    return 0;
}

控制台的输出结果是:

9
8
7
6
5
4
3
2
1
0
start(时钟打点): 5
finish(时钟打点): 6
CLOCKS_PER_SEC: 1000
CLK_TCK: 1000
运行时间(秒)(CLOCKS_PER_SEC): 0.001
运行时间(秒)(CLK_TCK): 0.001

Process returned 0 (0x0)   execution time : 0.322 s
Press any key to continue.

根据上面的输出结果也可以证明在 Windows 平台上的 CodeBlocks 编译器中常量 CLOCKS_PER_SEC 的值被定义为 1000.

注: 在 VC++6.0 环境中, CLK_TCKCLOCKS_PER_SEC 均被定义成 1000. 因此, 一般情况下, 在 Windows 环境中, 程序里使用 CLK_TCK 或者 CLOCKS_PER_SEC 的效果是一样的, 但是, 在 Linux 环境中只能使用 CLOCKS_PER_SEC.

Linux 下对于 CLOCKS_PER_SEC 这个常量的定义一般和 Windows 下是不同的.

Linux 下的 C 语言头文件通常都是放在 /usr/include 这个目录下.

(下面, 我将使用”Kali Linux 2019.1″进行本部分接下来的操作.)

/usr/include 目录下找到并打开 time.h, 在其中可以看到如下内容:

/* This defines CLOCKS_PER_SEC, which is the number of processor clock
   ticks per second, and possibly a number of other constants.   */
#include <bits/time.h>

在这个头文件里没有直接指明 CLOCKS_PER_SEC 的值, 而是选择包含了 bits/time.h 这个头文件. 于是, 我们在 /usr/include/x86_64-linux-gnu/bits 目录下找到 time.h 文件, 可以找到如下内容:

/* ISO/IEC 9899:1999 7.23.1: Components of time
   The macro `CLOCKS_PER_SEC' is an expression with type `clock_t' that is
   the number per second of the value returned by the `clock' function.  */
/* CAE XSH, Issue 4, Version 2: <time.h>
   The value of CLOCKS_PER_SEC is required to be 1 million on all
   XSI-conformant systems. */
#define CLOCKS_PER_SEC  ((__clock_t) 1000000)

由此我们知道, 在该 C 语言编译环境下, CLOCKS_PER_SEC 的值被定义成 1000000.

同样地, 在 Linux 下运行如下程序也可以看到当前编译环境下 CLOCKS_PER_SEC 的数值是多少:

#include <iostream>
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
using namespace std;

int main()
{
    int i=10;
    clock_t start,finish;
    double Times;
    start=clock();
    while(i--){
        cout<<i<<endl;
    };
    finish=clock();
    Times=(double)(finish-start)/CLOCKS_PER_SEC;
    cout<<"start(ticks): "<<start<<endl;
    cout<<"finish(ticks): "<<finish<<endl;
    cout<<"CLOCKS_PER_SEC: "<<CLOCKS_PER_SEC<<endl;
    cout<<"Total Times(s)(CLOCKS_PER_SEC): "<<Times<<endl;

    return 0;
}

运行后, 控制台的输出结果是:

9
8
7
6
5
4
3
2
1
0
start(ticks): 1124
finish(ticks): 1169
CLOCKS_PER_SEC: 1000000
Total Times(s)(CLOCKS_PER_SEC): 4.5e-05

另外, 在 time.h 这个 C 标准库中, 还定义了四个库变量, 其中库变量 clock_t 的作用是存储处理器时间, 因此, 在声明 clock() 函数的时候需要使用 clock_t 声明函数的返回值类型.

使用 clock() 计算程序中一个函数运行耗时的模板如下:

#include <stdio.h>

#include <time.h>
/*
导入 clock() 函数的头文件.
*/

clock_t start, stop;
/*
定义记录开始和结束时间的变量.
clock_t 是 clock() 函数的返回变量类型.
*/

double duration;
/*
记录函数运行时间, 单位为秒.
*/

int main(){

    start=clock();
/*
记录自 main() 函数被执行开始到本次 clock() 被调用一共走过了多少个 ticks.
*/

    MyFunction();//要进行计时的目标函数.

    stop=clock();
/*
记录自 main() 函数被执行开始到本次 clock() 被调用一共走过了多少个 ticks.
*/

    duration=((double)(stop-start))/CLOCKS_PER_SEC;
    //将时钟打点数转换成人类可以直观感知的时间秒数.

    /*
    不在测试范围内的操作写在这里, 例如输出 duration 的数值的操作等.
    */

    return 0;
}