0

我正在尝试将我的配置文件夹移动到我的 debian 服务器并将其存储在一个看起来最明智和最合乎逻辑的地方。我把所有东西都扔在家里，但现在看起来像这样：

软件： /opt/
网络文件：/var/www

但是，我必须将我的软件配置文件夹移动到服务器上的某个位置，以便它们可以符号链接到正确的位置。其中哪一个似乎最适合执行此操作：

/home/configs
/var/cfgs
或其他？

对不起，如果这看起来很迂腐，但你知道他们在说什么，所有东西都有一个位置；）

4

3 回答 3

2

根据FHS的说法，我建议使用/etc，这是放置特定于主机的系统范围配置的地方。

这假设该配置用于服务器应用程序（而不是由人类用户运行的应用程序）。

例如，我正在运行多个 zope 实例，其中包含配置文件

/etc/zope/instanceA/
/etc/zope/instanceB/
/etc/zope/test/
于 2012-10-01T15:20:31.770 回答
1

这是一种品味……你是这台机器上唯一的用户吗？
如果是这样也没关系，你可以把所有东西都放在家里。

如果是服务器，你必须确保你的配置目录有正确的访问权限。所以 $HOME 不合适。

还有一件事，如果它是 Debian 机器，请留/var/www在原处。那是许多与网络相关的软件包安装东西的地方。如果您开始四处移动，以后升级这些软件包时可能会遇到问题。

为每个软件创建一个用户也是一种品味……我假设这些服务用户没有登录，所以甚至没有为他们设置一个 $HOME 的真正目的。nologin如果这些软件可以从其他机器访问并且您想避免有人损害这些用户，我什至会将它们设置为安全手段。

于 2012-09-28T09:37:56.073 回答
0

系统范围的配置文件永远不应位于用户的主目录中。太容易破坏，或错误修改，不当更改权限。

/etc 在您管理多个系统时会出现问题。最佳实践：将副本保存在另一个目录中，并酌情通过 scp 推送到所有适当的系统。

如果你的包不是由系统包管理器管理的，例如从源代码安装的，这也会变得困难。如果您有多个版本的软件正在运行，那就更难了。

随着系统数量和类型以及软件包和版本数量的增加，管理变得更加复杂。对于一台用户很少的机器，在 /etc 中进行配置就可以了。

举个反例：考虑是否自定义foo安装。假设这是您的发行版提供的一个包，但您需要一个稍微不同的版本。

在默认位置安装配置文件可能会导致它在下次系统升级时被破坏。（可能与您在 /usr/bin 中的修改版本一起）

一种常见的做法是将您添加/修改的内容与系统文件树完全分开。当我是一名练习系统管理员时，我将所有特殊的东西都放在 /opt 中。

/opt
/opt/bin
/opt/sbin
/opt/usr/bin
/opt/usr/sbin
/opt/man
/opt/etc

这可以使内容远离系统，但并不总是清楚哪些文件属于哪个包。

具有许多可执行文件和手册页的包可能有自己的目录。Netpbm 和 ImageMagic、gnu utils、perl（模块）就是很好的例子。这为目录树增加了一个级别。

/opt/misc/bin #Contained anything that was one program, one man page
/opt/netpbm_2.1/bin
/opt/imagemagick_3.2/...
/opt/gnu_1.1/...

以及所有其他目录。例如全套 /opt/{package-version}/{bin|sbin|man|etc|var}

This is especially true for packages where you need to keep multiple versions.  e.g.

/opt/perl4.023...
/opt/perl5.8...

为大型包维护单独的树使切换变得容易——快速退出错误的更改。在大多数情况下，您将在用户的默认路径中保留符号链接以指向实际的二进制文件。例如 /usr/bin/perl -> /opt/perl5.8/bin/perl。这里的好做法是留下特定版本的链接。例如 /usr/bin/perl4 -> /opt/perl4.023/bin/perl

在某些地方，您需要处理多种架构。（我在一个地方有 11 个 unix 变体......）这可以为树添加另一个级别：

/opt/hpux/...
/opt/irix/...
/opt/sysv/...
/opt/solaris/...

通常我只在 NFS 文件共享上保持这种方式，并且本地副本被制作到单独的机器上。

The advantages of the complex hierarchy is ease of maintenance. If /opt/apache contains all the binaries, man pages, and configurtion files, then if you decide to change to lighttpd, you don't end up with lighttpd getting confused with apache's configuration file. (Both are called httpd.conf)

It also will mean that when you try a package, and remove it, you don't leave a litter of stuff here and there.

Generally you will not want the data for an application to reside in their /opt/application tree.

There are disadvantages:

  • If config files and var can be separated from /opt, then /opt can be read only except for upgrades. This can simplify backups.

  • One side effect of this, is the problem of executable path maintenance. Keep systemwide dot files (.cshrc, .tcshrc, .bashrc) that make the necessary path changes so that the bulk of your users aren't aware of changes. These files are sourced from their default dot files.

于 2013-03-13T18:33:15.637 回答