运维烂笔头

一个 SA 老兵的工作日志

发表于 更新于

起因

服务器上用 apt-mirror 来拉取某些软件官方的 apt 仓并本地建仓，用于本地服务器的软件安装和更新，这个大概也是众多运维工程师曾经做过的事情吧。

今天我在某一台服务器上做 apt-get update 时出错了，系统报 “http://xxx.xx.xx.xx/xxxxxxxxxxxxxxxxxxx/binary-i386/Packages.gz” 抓取失败。xxx.xx.xx.xx 是我自己建的 apt 仓，用来服务于内部服务器的，xxxxxxxxxxxxxxxxxxx 正是自建仓的路径，这下面当然没有 binary-i386 目录，因为服务器都是 x86_64 架构的，应该使用的是目录 binary-amd64 才对。

环境介绍

出错的服务器的操作系统是：Ubuntu 16.04.5 LTS (GNU/Linux 4.15.0-13-generic x86_64)

  1. apt 的配置文件里没有关于 i386 的设置
  2. source 里也没有关于 i386 的设置

原因简介

Ubuntu 的 amd64 系统中，i386 是作为额外的体系结构被支持的。证据如下：

1
dpkg --print-architecture;dpkg --print-foreign-architectures

会输出“amd64”和”i386”。

所以 apt 缺省是希望 apt 仓也同时能提供 i386 的软件包。而我用 apt-mirror 建仓时，没有指定同步抓取 i386 的软件包，故而当服务器来抓取 i386 相关数据时会出错（因为的确没有哇）。

解决方法

知道原因了以后解决起来相对就简单了，在 apt-mirror 的配置文件 /etc/apt/mirror.list 中将想要同步抓取的软件多写一行，用 deb-i386 替换 deb，然后再跑下 

1
apt-mirror

就会同时同步 i386 的软件包下来，这样客户端 apt-get 时就不会有错了。

进阶阅读

可以让 x86_64 系统架构的服务器仅安装 amd64 的软件吗？这样 apt-get 时也不会去抓群 i386 相关的东西了，这样的话也可以避免上面的错误。

回答是：当然可以！

首先，干掉系统现有的所有 i386 的软件包

1
apt-get purge ".*:i386"

接着，将 i386 从支持的体系结构里删掉

1
dpkg --remove-architecture i386

这样也可以达到目的！

发表于 更新于

缘起

我司用 PowerDNS 来维护域名，某天否然发现有纪录在 PowerDNS 已经更新了，但是客户端查询解析结果却迟迟没有更新。

排查问题

请求传输数据的一端

在用做 dns 查询用的服务器上（也是 PowerDNS），执行：

1
pdns_control reload;

然后在 log 里看到有错误输出：

Unable to AXFR zone ‘in-addr.arpa’ from remote ‘1.1.1.1’ (resolver): Remote nameserver closed TCP connection

(1.1.1.1 是主 DNS 服务器)

看了些文档，说有可能是数据文件太大导致传输失败，于是有直接测试了一下传输 zone：

1
dig in-addr.arpa @1.1.1.1 AXFR;

结果发现还是未能得到整个 zone 的数据，于是怀疑服务器端可能有问题。

在传输数据的一端

在主 DNS 服务器上（这里应该是 1.1.1.1），查看 log，发现有报错误：

Exception: All data was not consumed
TCP Connection Thread died because of STL error: All data was not consumed

仔细看了下文档，说有可能是待传输的 zone 的数据文件有问题，于是我又做了下检测：

1
pdnsutil check-zone in-addr.arpa;

发现一堆的数据（解析纪录）显然有问题，都备份好，然后删除之。

然后一一回头测试，这回都正常了。

问题根源

肯定是大家瞎改反向解析（in-addr.arpa）的数据记录导致的。

发表于 更新于

What is HSTS

HTTP Strict Transport Security (HSTS) is a web security policy mechanism which helps to protect websites against protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should only interact with it using secure HTTPS connections,[1] and never via the insecure HTTP protocol. HSTS is an IETF standards track protocol and is specified in RFC 6797.

The HSTS Policy is communicated by the server to the user agent via an HTTPS response header field named “Strict-Transport-Security”.[2] HSTS Policy specifies a period of time during which the user agent should only access the server in a secure fashion.[3]

以上来自于维基百科

大概意思是说 HSTS 是一个 web 安全策略装置，用于保护 web 站点免受协议降级攻击和 cookie 劫持。

阅读全文 »

发表于 更新于

缘起

我厂办公室测试小机房有一些运算资源，但是其网络是不能直接上公网的，而是通过一个内部代理（内部域名是：proxy.xxxdev.com，端口 3128）来上公网的。

但是现在部署环境，多半需要在命令行下折腾，而且还多半需要不停的从公网下东西（安装），所以，怎样在命令行下（shell 里）使用代理来上公网就成了一个绕不开的话题……

阅读全文 »

发表于 更新于

缘起

起因自然是我厂某台 CentOS 7.x 的机器需要重置密码，然后我就想按老套路：重启进单用户，再重设密码。没想到 CentOS 7.x 的系统跟 CentOS 6.x 来说有了很大的变化，于是我又只好翻了下文档，重新学习了一下。以下是具体操作步骤：

阅读全文 »

发表于 更新于

缘起

这个项目的目的主要是为了解决 Linux
服务器在本地解析域名中碰到的几个问题：

  1. nameserver 中一部分有故障（包含宕机了）的问题
  2. nameserver 中一部分性能有问题的问题
  3. 有 HA，但有时候服务切换没有期望得那样准确、迅速

主要为了解决以上三个问题，于是有了内网域名解析优化的需求。

阅读全文 »

发表于

缘起

最近上面在开会嘛，职能部门也许是要展示下“肌肉”：“不是我搞不了你，我只是平时懒得鸟你。”我猜大概就是这么个原因吧，结果就是：最近这段时间大家的“科学上网”纷纷中招，不好使了。我司原来用的 SS 改良的版本，中招了，至于怎么解决的，不在本篇讨论的范围之内。

我主要说下家里的情况，家里原来也是 SS 方案，这段时间也不行了，通常是早上不通了，改下端口，然后到晚上又不行了，然后又改端口，搞了两次才是反应过来是被盯上了。心中大呼侥幸！这要是不封端口直接封 IP 我可咋整呀？！就冲这点来讲不得不说职能部门真是良心单位哈，值得点个赞！

现有资源

  • 米国 VPS 一台（Ubuntu 16.04）
  • 家里路由器一台（OpenWrt 14.07，bcrm63xx 架构）

以前也是这情况，不过以前跑的是 SS，据说 SSR 比 SS 更不容易被 ban，所以这次我的方案是用 SSR 替换掉原来的 SS。

阅读全文 »

发表于

方法一

1
curl qrenco.de/http:\/\/m.theyan.gs

系统输出：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
█████████████████████████████████
█████████████████████████████████
████ ▄▄▄▄▄ █ ▀▀▄  ██▀█ ▄▄▄▄▄ ████
████ █   █ ███ ▄▄▄████ █   █ ████
████ █▄▄▄█ █ ▄▄ █▀▄███ █▄▄▄█ ████
████▄▄▄▄▄▄▄█ █ ▀ █▄▀ █▄▄▄▄▄▄▄████
████ ▄ ██▄▄▀   ██ ▄▀▄   ▄▀█  ████
████▄▀█▀▀ ▄▄▄▀█▄█▀█  █▄ ▀ ▄█▄████
████▄▄▀▀▀▀▄ █ █▄ ▄█▀ █ ▄███▀ ████
████▄▄  ██▄▀ ▀ ▀ ▄ ▄█▄█▀ ▄▄█▄████
████▄▄▄▄█▄▄█ ▄▄██  ▄ ▄▄▄ █▀▄▀████
████ ▄▄▄▄▄ █▀▄▀▄█▀█▀ █▄█ ▄█▀ ████
████ █   █ ██▀ ▄ ▄█ ▄ ▄▄  ▀ ▄████
████ █▄▄▄█ █  █▀ ▄  ▀ █▀ ██▄▄████
████▄▄▄▄▄▄▄█▄████▄▄█▄█▄██▄██▄████
█████████████████████████████████
█████████████████████████████████

方法二

1
echo "http://m.theyan.gs" | curl -F-=\<- qrenco.de

得到的系统输出是：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
█████████████████████████████████
█████████████████████████████████
████ ▄▄▄▄▄ █ ▄▄ █ ██▀█ ▄▄▄▄▄ ████
████ █   █ ██▄█▀▀▄████ █   █ ████
████ █▄▄▄█ █ ▀▀▄ ▀▄███ █▄▄▄█ ████
████▄▄▄▄▄▄▄█ ▀▄█▄█▄▀ █▄▄▄▄▄▄▄████
████▄▄ █▀ ▄▀ ▄█▄  ▄▀▄   ▄▀█  ████
████▄▄ ██▄▄  ▄ ▀ █▄  █▄ ▀ ▄█▄████
█████▀▄▄▀█▄▀▄▄ ██ ▄▀ █ ▄███▀ ████
████▄▄ █  ▄▀  ▄▄█▀█▄█▄█▀ ▄▄█▄████
████▄▄▄▄██▄▄▀▄ ▄ ▄█▄ ▄▄▄ █▀▄▀████
████ ▄▄▄▄▄ █▀▄▄▀ ▄ ▀ █▄█ ▄██▄████
████ █   █ ██ ▄██   ▄ ▄▄  ▀▀▄████
████ █▄▄▄█ █ ▀▀▄█▀█ ▀ █▀ ██▄▄████
████▄▄▄▄▄▄▄█▄▄█▄▄▄██▄█▄██▄██▄████
█████████████████████████████████
█████████████████████████████████

检测结果

用二维码识别软件检测上面这两个二维码，发现都是：“http://m.theyan.gs”

发表于

缘起

我厂原来的权威 DNS 服务器放在阿里云上的（三个完全不同的节点每个节点一台），但现在这几个节点要撤了，所以这些个权威 DNS 服务器必须要要迁往别处了。

阅读全文 »

发表于

问题初现

最早发现问题时是在做一个测试，把某个域名解析到内网的几台机器上（10.0.0.9 和 10.0.0.119），结果用客户端（10.0.0.200 和 10.0.0.201，都由于特殊原因没有关掉 IPv6）去连接测试时发现，连接都跑到 10.0.0.119 上了，10.0.0.9 上几乎没有连接！

阅读全文 »
0%