SSH反向代理,邮件服务器故障排除典型案例

让AWS虚机访问公司内网资源(SSH反向代理),aws虚机

如何清理 Linux 系统开机启动项?,清理linux开机启动

一般情况下,常规用途的 Linux 发行版在开机启动时拉起各种相关服务进程,包括许多你可能无需使用的服务。-- David Both

本文导航◈ 查看开机启动项09%◈ 哪些服务能够禁止?37%◈ 系统启动时发生了什么?62%

大部分 Linux 发行版都会在开机的时候启动各种相关的服务进程,其中有很多你根本都用不上的:蓝牙、 Avahi 、调制解调管理器甚至 pppd-dns 等等,你甚至根本不知道这些都是什么东西。

好在我们有 Systemd ,它给我们带来了许多工具帮我们查看系统启动是的状况,当然也可以让我们控制系统启动时候的运行选项。我将会为你详细解读关闭某些无用进程的方法,前提是在 Systemd 类发行版。

查看开机启动项

通常情况下,你能用 /etc/init.d 查看系统引导时启动的服务项。但是 systemd 会用不一样的展现方式,下面是一些命令,用于展示开机启动时的进程项。

你可以看到,这里头有一项是蓝牙,我不需要使用它,那么我应该怎样关闭并阻止它在开机时后启动?

完成上面的操作之后,用下面的命令来确定自己是否成功。

这里的停用并不彻底,因为其他的服务进程仍旧可以将它唤起。如果要完全阻止开机启动的话,卸载不是个好方法,像下面这样把它掩盖起来就可以了:

我建议在持续使用一段时间并没有造成任何负面影响之后再选择卸载。

通过执行命令可以获得如下服务列表:

有一点需要注意:静态服务的启动和禁用状态无法改变,因为静态服务被其他的进程所依赖,而这个状况下并不是它们自己运行。

哪些服务能够禁止?

如何知道你需要哪些服务,而哪些又是可以安全地禁用的呢?它总是依赖于你的个性化需求。

这里举例了几个服务进程的作用。许多服务进程都是发行版特定的,所以你应该看看你的发行版文档(比如通过 google 或 StackOverflow)。

◈ accounts-daemon.service 是一个潜在的安全风险。它是 AccountsService 的一部分,AccountsService 允许程序获得或操作用户账户信息。我不认为有好的理由能使我允许这样的后台操作,所以我选择掩盖mask该服务进程。◈ avahi-daemon.service 用于零配置网络发现,使电脑超容易发现网络中打印机或其他的主机,我总是禁用它,别漏掉它。◈ brltty.service 提供布莱叶盲文设备支持,例如布莱叶盲文显示器。◈ debug-shell.service 开放了一个巨大的安全漏洞(该服务提供了一个无密码的 root shell ,用于帮助 调试 systemd 问题),除非你正在使用该服务,否则永远不要启动服务。◈ ModemManager.service 该服务是一个被 dbus 激活的守护进程,用于提供移动宽频broadband(2G/3G/4G)接口,如果你没有该接口,无论是内置接口,还是通过如蓝牙配对的电话,以及 USB 适配器,那么你也无需该服务。◈ pppd-dns.service 是一个计算机发展的遗物,如果你使用拨号接入互联网的话,保留它,否则你不需要它。◈ rtkit-daemon.service 听起来很可怕,听起来像是 rootkit。 但是你需要该服务,因为它是一个实时内核调度器real-time kernel scheduler。◈ whoopsie.service 是 Ubuntu 错误报告服务。它用于收集 Ubuntu 系统崩溃报告,并发送报告到  。 你可以放心地禁止其启动,或者永久的卸载它。◈ wpa_supplicant.service 仅在你使用 Wi-Fi 连接时需要。

系统启动时发生了什么?

Systemd 还有另外命令一些帮助我们调试开机启动时出现的问题。使用这一命令可以重现系统启动时候的所有消息。

输入 journalctl -b -1 命令可以重现你上一次启动时候的信息,journalctl -b -2 可以重现倒数第 2 次启动,以此类推。

这个命令会把所有信息都给打印出来,这可能会造成一定干扰,因为有时候完全无需关注所有信息,只需要查看重点部分就可以了。所以,我们可以使用过滤器功能来快速发现目标。我们试着以进程 1 为例来演示一下。

从这些消息里我们判断出正在或者即将启动的进程。

一个最有用的命令工具之一 systemd-analyze blame,这个命令可以显示进程耗时,帮助我们发现耗时最长的进程。

这个特定的例子没有出现任何异常,但是如果存在系统启动瓶颈,则该命令将能发现它。


via: 

作者:David Both 

译者:penghuster 

校对:wxy

邮件服务器故障症状描述:

背景说明

今天我要将AWS虚机升级到beta版本并进行一些测试。

由于beta版本只在公司内网提供,因此我需要将升级用的文件手动拷贝到AWS虚机中。原始的方法,很容易理解:

然而这就遇到一个问题,因为镜像文件有4.2GB大小,传输过程不仅占用带宽资源,而且还会浪费很多时间。

邮件服务器A和邮件服务器B,作前后端设置,前端接收邮件后,投递给后端服务器内的邮箱,当前前端接收外部邮件后,无法投递给后端邮箱,导致邮件积压在前端服务器,内部邮件传递需要延迟25分钟左右到达。
 
通过察看前后端服务器的各类服务,发现所有服务均正常,由于无法投递给后端服务器,所以首先判断可能是后端服务器出现了问题,决定重启动。
 
重启动耗时4分钟,这时候察看前端队列,发现已经正常投递给后端服务器,认为问题解决,可能是意外原因导致后端服务器服务不正常。
 
但是经过5分钟的观察,发现,问题仍然存在,外部投递邮件仍然积压在前端服务器上,于是又深层次查找问题,发现如下症状
在Message Submitted to Advanced Queuing 和 Started Message Submission to Advanced Queue两步用时超过10分钟,在Message Submitted to Categorizer 和Message Categorized and Queued for Routing 之间历时接近10分钟,根据这个线索,查找资料,得到如下类似症状
 

研究过程

由于全局编录服务器问题而导致邮件传递出现延迟
全局编录问题可能导致邮件传递出现延迟。在这种情况下,会生成 NDR 以通知发件人这一延迟。可以使用邮件跟踪中心来诊断这些问题。下面的示例显示了从邮件跟踪中心所收集到的数据:
6/22/2001 3:54 PM Tracked message history on server CONTOSO-MSG-01
6/22/2001 3:54 PM SMTP Store Driver: Message Submitted from Store
6/22/2001 3:54 PM SMTP: Message Submitted to Advanced Queuing
6/22/2001 3:54 PM SMTP: Started Message Submission to Advanced Queue
6/22/2001 3:54 PM SMTP: Message Submitted to Categorizer
6/22/2001 4:24 PM SMTP: Started Outbound Transfer of Message
6/22/2001 4:24 PM Message transferred out to FOURTHCOFFEE.COM through SMTP
6/22/2001 4:24 PM SMTP: Message Submitted to Advanced Queuing
6/22/2001 4:24 PM SMTP: Started Message Submission to Advanced Queue
6/22/2001 4:24 PM SMTP: Message Submitted to Categorizer
6/22/2001 4:24 PM SMTP: Started Outbound Transfer of Message
6/22/2001 4:24 PM Message transferred out to FOURTHCOFFEE.COM through SMTP
6/22/2001 4:24 PM SMTP Store Driver: Message Delivered Locally to Store
在上面的示例中,应注意到邮件在邮件分类程序中延迟了 30 分钟,之后才开始进行出站传输,并且最终被送达。在这些情况下,应通过运行 Nltest 工具来确定 Exchange 使用哪一台全局编录服务器。具体步骤在本主题前面的“通过使用移动邮箱工具将收件人移到 Active Directory”中已说明。然后,调查所涉及到的全局编录服务器。下面是全局编录服务器的常见问题:
• 全局编录服务器超载或工作过度。
• 全局编录服务器出现性能问题。
• 内存不足。
• 硬盘空间不足。
• Exchange 2000 与全局编录服务器之间出现暂时性的网络问题。
• 使用同一个全局编录服务器的 Exchange 服务器过多推荐的 Exchange 处理器与全局编录服务器处理器的比率是四比一)。

方案1【被舍弃】

解决办法我首先想到将目录http://download.eng.pek2.redhat.com/pub/rhel/rel-eng/RHEL-7.4-20170621.0/compose/Server/x86_64/debug/tree/拷贝到虚机上,然后用它来做YUM源进行升级。但我很快就发现自己并不能确定哪些package是升级所需要的,因此只能上传全部的文件,这样做并不能有效解决问题。

要点:

方案2【被舍弃】

其次,我想到在AWS虚机上安装客户端,通过VPN方式访问内网资源。这样做当然是可行的,只是openvpn配置起来需要将证书拷来拷去,这使我担心潜在的安全问题,也担心后续会过多地占用VPN服务器资源,因此这个想法只能作罢。

邮件跟踪日志可能会起到一种误导作用。例如,如果全局编录服务器正常工作,并且邮件分类程序也正常工作,但是远程 SMTP 服务器不可用达三十分钟,则邮件跟踪日志可能与上面显示的示例日志类似。此外,如果邮件必须在本地传递,并且 Exchange 存储执行速度很慢,则邮件跟踪日志将显示出“邮件已提交到邮件分类程序”与“邮件已传递到本地存储”之间存在很大的时间差异。
重现问题时,应从全局编录服务器中使用系统监视器日志。这有助于您诊断这些问题。再次使用全局编录服务器可以解决这些问题。要解决这些问题,可以为每一台 Exchange 服务器指定一台全局编录服务器。 

本文由ca88手机版登录发布于亚洲城官网,转载请注明出处:SSH反向代理,邮件服务器故障排除典型案例

TAG标签: ca88手机版登录
Ctrl+D 将本页面保存为书签,全面了解最新资讯,方便快捷。