Arch Linux是否适合服务器环境?


30

您认为Arch Linux适用于服务器环境吗?它的滚动发行模型和简单性似乎是一件好事,因为一旦安装了它,就不需要像其他发行版的发行模型那样重新安装。

但是,不断升级不会引起稳定性问题吗?Arch Linux使用最新的STABLE版本的软件,尽管它具有最先进的功能。


一般邮件列表中,您可以在最近作为网络服务器线程的Arch下找到有用的讨论和评论。
mloskot 2012年

Answers:


33

Arch作为服务器操作系统的最大问题可能是不清楚在升级后应用程序可能在何时何地中断。通常,在进行任何形式的升级之前,您必须跟上Wiki和论坛上正在发生的事情。使用Debian和CentOS,您可以完全放心,任何升级都不会破坏任何应用程序,因为在STABLE分支上完成的升级通常是安全性/错误修复程序。


27
但是,您是否应该在推出更新之前先进行测试?我们正在生产中运行一些Arch盒,并每周大约在一些内部机器上测试更新。当一切都确定能正常工作时,我会发布更新。
埃里克·科尔曼

13

尽管我喜欢arch,但我不会在生产环境中使用它。首先,在生产环境中,您需要稳定且经过良好测试的产品。另外,由于剥离的程度很大,因此您需要手工制作自定义脚本或手动设置内容(有时会很不错,因为您确切地知道系统中正在运行的是什么,但是非常糟糕,因为它花费了太多的时间进行配置)。除此之外,由于它没有在生产环境中广泛使用,因此如果出现问题,您将无法获得使用Debian或Fedora时所能获得的支持(Arch社区很棒,但老实说,规模并不大)作为Debian或Fedora的)

总而言之,我认为这非常适合桌面使用,但不适用于生产环境


6

是。

优点:

  • 开箱即用的系统非常少,特别是在低端机器/ VPS上,性能非常出色。没有不需要的服务-与CentOS 7相比,后者启动了几项与VM相关的服务,这些服务甚至在我使用裸机运行时也不适用于我。

  • 最新的软件和大型存储库;当回购中没有某些东西时,我在CentOS上浪费了很多时间,我被迫从源代码进行编译或安装第三方RPM /回购,然后最终陷入依赖地狱,因为这些第三方RPM是与官方仓库的升级冲突。

  • systemd,尽管其他发行版(甚至是Ubuntu)都切换到了它,所以它不是专业人士,而是任何不错的发行版都可以期望的东西。

  • 合理的网络配置工具。没有台式机级的Networkmanager也没有防火墙(查看CentOS / RHEL)。

  • 包管理器,可以按照锡盒上的说明进行操作。软件包管理器不会尝试通过自动配置或启动刚刚安装的服务来“帮助”您(查看Ubuntu / Debian)。它的速度也更快,更好yum,甚至可能比快一点apt-get

  • 安装过程不会强迫您使用任何默认设置,并且提供了很大的自定义空间-将其与CentOS / RHEL进行比较,后者会强迫您使用LVM并进行交换,而这并非总是需要的(实际上,对于我而言几乎从来没有)

  • /usr/bin/python实际上是最新的Python 3,而不是史前的Python 2.7。对于大多数其他发行版而言,这始终是我的问题,而且您也无法轻易更改(至少不是在整个系统范围内),因为它将破坏许多依赖它的应用程序。

缺点:

  • 有些升级需要人工干预,并且可能会中断。我建议在虚拟机中拥有生产环境的副本,并在虚拟机上部署升级之前测试升级。

  • 没有默认的工作配置。对于只想运行apt-get并安装其默认的不安全LAMP堆栈以部署其脆弱的易受攻击的PHP应用程序并污染Internet的人而言,这是很不利的。当然,对于认真的人来说,这实际上是一个优势,因为它迫使您在启动服务之前先检查配置文件。

  • 不支持SELinux。有GRSecurity及其RBAC,但是您需要一些时间来习惯它并对其进行微调。

我不同意您获得的支持较少的事实。当然可以。那是不利吗?我认为没有。Arch中几乎没有什么可以打破的,需要熟悉Arch的人的支持。通常,如果需要支持,则需要特定软件的支持,在这种情况下,您会询问其开发人员,而您正在运行Arch的事实变得无关紧要。

对我来说,使用Arch比使用CentOS及其Networkmanager,firewalld和其他不需要的服务(可以将其禁用,但是已经浪费了时间)更容易,也更省时。另外,我知道系统上运行的每一项服务,因为我会安装它,没有偷偷摸摸的软件会困扰我一个错误,即使我刚刚安装了系统也想打电话回家。


5

我总是建议以下之一:

  • CentOS的。这是一个免费的RHEL克隆,这意味着你会得到一个很长的周期支持(7岁),在此期间,你可以得到公正的安全修复和小的改进,因此保持系统打补丁是非常,非常容易。另外,许多“商业”软件都针对RHEL,因此它们更易于在CentOS上安装。缺点:与yum / rpm相比,我更喜欢apt / dpkg,不容易在其上运行最新的软件,软件选择有些简陋

  • Ubuntu LTS。其实我还没有使用过,但是它的支持周期很长,而且是Debianish

  • Debian测试。Debian是我最喜欢的发行版,运行得非常好,并且有一个非常庞大的软件包选择,可以很好地组合在一起。进行补丁修复比较耗时,但是安装软件更容易(例如,有很多东西可以立即打包)。

我建议考虑将Arch Linux用于这三者中的一者,看看是否值得。


2
您会在生产服务器上使用Debian测试吗?这对我来说毫无意义。您多久修正一次更新期间会中断的问题?
杰森·伯格

1
@Jason:更令人担忧的是,尽管Debian现在具有官方的测试安全支持,但它不如稳定或不稳定,因为用于测试的安全更新的隔离时间减少了,但非零,并且由于未满足依赖关系而可能被延迟。
吉尔(Gilles)“所以,别再邪恶了”,2010年

当我想运行某些最新软件时(例如让CentOS上运行Rails应用程序有点麻烦,但是在Debian Testing上却很容易...),我转向测试。我使用debsecan仅提取安全更新,并且通常相当稳定。如果我将其用于核心产品,我想先进行广泛的测试,然后再在测试盒中发布更新。当然,我也应该在CentOS框中执行此操作:-p
alex

1
“ [Debian]进行修补需要花费更多时间” –为什么更新和修补更加困难?就像CentOS更新一样,它只是一个apt-get upgrade。也许我缺少了一些东西……
Lao Lam

2
我真的看不出这个答案如何解决这个问题,即“ Arch Linux是否适合服务器环境?”。建议其他三个发行版,然后建议读者将自己与Arch Linux进行比较,并不构成答案。
乔恩·本特利

1

自2013年以来,我在生产环境中运行多台Archlinux服务器,它的运行就像一个魅力。

确保必须经常运行更新,以确保更新顺利进行,并在升级之前始终检查archlinux页面。

就是这样,最终您将有更多的麻烦将RedHat / CentOS从6升级到7(几乎不可能)或将SLES / SLED从11升级到12,以此类推。

您不断进行一些小更新,这些更新会不时引起一些行动,但是最近五年来我从未遇到过大的事情。

而且,如果内核,openssl,bash或其他内容中存在安全漏洞,那么您总是会保持最新状态,那么您将在几小时而不是几天到几个月的时间内获得更新。

例如,我的服务器已完全升级,可以抵御幽灵v1,幽灵v2和崩溃。我敢肯定,只有1%的人员在这里发布了针对这三者的服务器。

它快速,安全,稳定(!),并且您拥有最新的软件,可以使您摆脱很多麻烦。

我强烈建议在服务器上使用Archlinux,唯一的缺点是您必须知道自己要做什么。您应该至少安装一次LFS系统,以便了解有关Linux发行版的构建和工作原理的基础知识。

在服务器环境中,我发现唯一比Archlinux更坚如磐石的服务器系统是Gentoo。有一个700天没有更新的Gentoo系统,一小时后该系统是最新的,并且运行时唯一的停机时间是一次重启。

但是其他发行版升级时,诸如Debian / Ubuntu,RedHat,SUSE之类的系统将完全使您烦恼。RedHat甚至积极地劝阻您进行发行版升级,并建议重新安装(根据官方文档)。

因此,是的,RedHat比Archlinux更稳定地升级,但这仅是因为您没有获得大的升级。当你得到它们时,你就被搞砸了。


0

我要说的是,告诫您永远不要只在生产服务器上运行pacman -Syu并保留系统驱动器的差异映像备份,以防损坏时可以在文件系统上滚动备份。

比Debian测试/ sid更加有用(破损的网络更少)。如果您想要最先进的软件包和最少的安装量,Arch是最好的发行版,但是手动管理需要很大的便利。


0

服务器发行版的主要区别在于,您仅获得安全更新,而在Arch上,还获得了软件包的主要修订版,这可能会破坏内容。

如果要使Arch适合服务器,则只需更改镜像(从中获取软件包的位置)即可。例如:

  • 拱镜:您可以在其所有者发布后的第一周内获得次要/主要软件包的更新。
  • manjaro-unstable:与拱镜相同,但对某些软件包进行了双重检查。一些主要的错误不会使其投入生产。
  • manjaro-beta:与拱镜相同,但所有包装均经过三重检查。大多数主要错误都不会使其投入生产。
  • manjaro-stable:与拱镜相同,但是在几个月内对包裹进行了多次检查。很少有小错误可以投入生产。

以同样的方式,如果使用专门为服务器设计的镜像,并且只获得较小的修订,那么在服务器上使用arch是安全的。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.