问题[documentation](server)

我使用以下命令从源代码编译了 Haproxy LTS 2.2 版本：

make TARGET=linux-glibc USE_PCRE=1 USE_OPENSSL=1 USE_ZLIB=1 USE_CRYPT_H=1 USE_LIBCRYPT=1

编译过程中没有错误。这是我的 Haproxy 配置：

global
    log         127.0.0.1 local2

    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     4000
    user        haproxy
    group       haproxy
    daemon
    
    # turn on stats unix socket
    stats socket /var/lib/haproxy/stats

defaults
    mode                    http
    log                     global
    option                  httplog
    option                  dontlognull
    option http-server-close
    option forwardfor       except 127.0.0.0/8
    option                  redispatch
    retries                 3
    timeout http-request    10s
    timeout queue           1m
    timeout connect         10s
    timeout client          1m
    timeout server          1m
    timeout http-keep-alive 10s
    timeout check           10s
    maxconn                 3000

frontend http-in
        bind 192.168.123.40:80
        acl gerrit hdr(host) -i gerrit.example.local
        acl jenkins hdr(host) -i jenkins.example.local
        use_backend gerrit if gerrit
        use_backend jenkins if jenkins

backend gerrit
        server gerrit 127.0.0.1:8080

backend jenkins
        server jenkins 127.0.0.1:8081

当我使用haproxy -c -q -V -f /etc/haproxy/haproxy.cfg命令检查配置时，出现以下错误：

[NOTICE] 226/130914 (35193) : haproxy version is 2.2.2
[NOTICE] 226/130914 (35193) : path to executable is /usr/sbin/haproxy
[ALERT] 226/130914 (35193) : parsing [/etc/haproxy/haproxy.cfg:33] : unknown keyword 'bind 192.168.123.40:80' in 'frontend' section
[ALERT] 226/130914 (35193) : Error(s) found in configuration file : /etc/haproxy/haproxy.cfg
[ALERT] 226/130914 (35193) : Fatal errors found in configuration.

我检查了文档，它允许bind在前端部分使用关键字 http://cbonte.github.io/haproxy-dconv/2.2/configuration.html#bind （按字母顺序排序的关键字参考）

当我在前端部分注释掉bind关键字时，实现了更多的mindfuck。然后错误说：

[WARNING] 226/132456 (36642) : config : frontend 'http-in' has no 'bind' directive. Please declare it as a backend if this was intended.?

我在理解 FreeBSD 关于“配置系统日志”的文档时遇到问题：

https://www.freebsd.org/doc/handbook/configtuning-syslog.html

文档：“默认情况下，系统启动时启动 syslogd。”

到目前为止，一切都很好。但在下一句中它说：

“这由/etc/rc.conf中的变量syslogd_enable控制”

据我了解，这是一个矛盾。因为默认情况下syslog_enable没有在 /etc/rc.conf 中设置。而且由于 syslogd 启动时没有在 /etc/rc.conf 中激活，因此它必须在其他地方进行控制。

所以这是我的问题：如果我想在启动时通过以下方式将标志传递给 syslogd：

syslogd_flags="myflags"

我是否还需要设置 syslogd_enable="YES" 以确保 syslogd 启动，即它的启动由 /etc/rc.conf 控制

或者

仅设置 syslogd_flags 并希望 syslogd 将在系统启动过程中的其他位置启动就足够了吗？

我正在审查（相当大的）网络的安全性。有几千个交换机、几百个路由器、几百个接入点、十分之一的 FW、IPS 等等。个人电脑和服务器处于规模庞大的一面。

我已经向网络负责人（不是实际的管理员）询问了几个星期的网络地图，并获得了一些非常高级的 PPT 图纸和一些网段的 2 级 visios。我必须从不覆盖整个网络的配置文件和监控工具中找出安全元素的位置。

我一直被告知，一个好的管理员需要及时了解他/她的领域的最新文档，例如服务器、网络或任何向管理员支付的费用。当我是一名管理员时，我试图按照该规则工作。

所以，现在，这些负责人告诉我，保留一个包含一些 3 级详细信息、基本安全元素、有关 IP 寻址和已定义 VLAN 的额外文档的网络地图信息太多，他们无法保持更新，因此他们决定不生成文档并依赖部分覆盖网络的个人知识和监控工具。

就我个人而言，我觉得这些只是一堆借口，即使网络规模如此之大，因为他们花了数周时间来识别关键信息。尽管如此，我想从社区示例中了解这些文档如何被证明在以下方面有用： - 照常经营管理。- 网络中断等技术事件。- 安全事件。

我从来没有管理过这么大的网络，所以我可能是错的，负责人的观点可能是正确的，所以，如果你这么认为，你能否举出实际的例子来说明如何记录真正的大型网络以确保管理员的理智和有效性？

哪些是最新网络地图的有效替代品？

TL：博士？好吧……这里：

除了雇用或外包给技术作家之外，是否有技术作家在其行业中采用的基本标准/惯例/实践可以从中学习，以便创建适当的 IT 文档并随着时间的推移维护该文档？

在为员工的内部 IT 使用和外部使用编写各种文档时，很明显，我们的员工在文档方面都有自己的风格。

从我们的质量文档和受控文档中提取，IT 使用了 SOP、WI 的各种模板以及用于 IT 质量文档的各种表格。这些文档虽然不一定对 IT 内部的日常运营有用，但确实可以帮助员工和公司解决 IT 人力资源问题、合规性等问题，并且通常写得很好、定义明确，并且至少遵循质量部门的模板和文档标准（如版本控制、ECN 等）

但是我们实际的 IT 文档写作仍然缺乏真正的约定/标准。 有些人会使用 ScreenSteps 之类的 3rd 方工具，而其他人则只需使用 Word 并创建一个简单的大纲，例如：

1. 打开app
2. 点击“开始全球热核战争”
3. ...
4. 利润

内部 IT 文档实际上更糟糕，基于员工或顾问当时认为足以记录他们自己的记忆或基于他们选择的编辑器（vi、word、excel、powerpoint、餐巾纸、内部 wiki）的任何内容。当员工离开或休假时，问题就出现了，甚至连基本信息都被弄得乱七八糟。 有时只有文件日期是数据是否仍然相关的指标。

虽然简单的大纲、实际的屏幕截图，甚至完整的高清视频都很好，但我们没有真正的 IT 技术作家，不禁认为我们在这方面缺乏。

我们可以为我们的文档制定我们自己的标准以及批准的模板吗？是的，但为什么要重新发明轮子？如果技术作家的“公会”中已经存在这样的标准和惯例，我们最好遵循这些惯例，以便我们的文档清晰、简洁和专业。

为了避免被告知“ Google It ”，我确实查看了一些显示一些格式化实践的网站，虽然这个 SF Q：IT 文档平台有助于找到处理写作的平台和软件，但它没有讨论内部是否真的有标准行业。

那么，除了雇用或外包给技术作家之外，是否有技术作家在其行业中采用的基本标准/约定/实践可以从中学习，以便创建适当的 IT 文档并随着时间的推移维护该文档？

我们有相当好的环境文档（AsciiDoc 格式），最近允许另一个人在不到 30 分钟的时间内从头开始重新创建整个设置。
然而，我注意到在初始设置之后，很容易发生对系统进行小的更改（比如：inetd 被禁用，我的 IMAP 服务器在一个额外的端口上监听 ManageSieve 连接，一个新的路由器被添加到 exim 配置）不要' 立即出现在文档中（如果有的话）。

我的想法是通过（部分地？）从配置文件和其中的注释生成文档来避免这个问题——实现这个的一种方法可能是/etc放入/usr/local/etc一些源代码管理系统（比如 - git），然后运行一个在每次提交时重新生成文档的脚本。但是，我不确定这是否会矫枉过正和/或太难正确（毕竟，我不希望我的文档中有源文件的完整副本，而只是差异）。

其他人如何避免服务器文档过时 - 是否有一种好方法可以自动保持它们同步，或者您是否只是在修改系统的同时更新文档？

我正在从事一个项目，我想为各种项目执行主机文档。这些项目的一部分将来自 Powershell，其余部分将来自 NMAP。对于 Powershell 部分，我正在尝试构建类似于SYDI-Server的自主开发的东西项目。它将使用 Powershell 而不是 WMI，并允许使用更大、更简单的方法从远程机器获取各种结果。另外，SYDI-Server 项目已经有一段时间没有更新了。NMAP 片段将用于在远程主机上执行一两次扫描并返回结果，以便 Powershell 可以使用或使用这些结果并将它们添加到正在生成的最终报告中。这个想法类似于报告是一个 MS Word 文档，它是从 Powershell 输出的，其中包含主机文档所需的所有元素。

综上所述，有没有办法让数据从 Powershell 共享或来回发送到 NMAP？有没有办法在 Powershell 中使用或解析 NMAP 的结果以进行进一步操作？

假设一家大型企业在（在此处插入随机位置）开设了一个新办公室，并希望新同事尽快上手。假设这家企业是一个非常典型的企业，环境复杂，历史悠久，几乎完全缺乏文档。

已经决定的是，新同事将获得最典型任务的 howto 样式文档，并将获得一些更复杂系统的基本架构文档。

关于改进这个过程的任何想法？更具体地说，这样的howto文档应该看起来有什么帮助？

我的团队需要在内部发布文档。目前，它遍布各地，这意味着我们经常不得不到处搜索才能找到东西。

我们想在一个地方发布所有内容。阻止我们的主要是访问控制——现有的 wiki 不属于我们，我们做不到。

什么是发布文档的最佳工具，最适合这些要求：

• Web 前端 - 读者使用浏览器访问文档
• 放置文档的单一位置
• 通过单个文档或文档集（文件夹、“站点”的分支……）进行访问控制
• 如果您无权访问文档，则看不到该页面/文档/文件夹的链接。
• 内置编辑器或我的用户熟悉的东西（例如 Word）
• 内置版本控制会很好

另外，你能想到我应该指定的其他标准吗？

Alfresco的用户指南在哪里，例如Nuxeo的出口： Nuxeo 文档管理：用户指南

我们刚刚交付了一个“成熟”的 48 端口交换机，用于测试、部署和一般欺诈。由于我们将不断地修补补丁，因此我们需要一个图表，以便我们知道哪个端口在哪个 VLAN 上。

有没有人在他们的互联网旅行中看到过这样的模板/图表/密钥？我们希望比 Excel 中的两排 24 行更时尚一些 - 适合像这样的经典网络套件！