我们有一个由我们公司一半以上使用的wiki。 一般来说，它一直非常积极地接受。 然而，人们担心安全问题 – 不要让机密信息落入坏人手中（即竞争对手）。 默认的答案是创build一个复杂的安全matrix，定义谁可以根据创build者来读取哪个文档（wiki页面）。 我个人认为这主要是解决了错误的问题，因为它在公司内部造成了障碍，而不是对外部世界的障碍。 但有些人担心，客户现场的人可能会与客户分享信息，然后再与竞争对手分享信息。 这样一个matrix的pipe理是一个噩梦，因为（1）matrix是基于部门而不是项目（这是一个matrix组织），和（2）因为在维基的所有页面定义上是dynamic的，所以今天什么是保密的明天不要保密（但历史总是可读的！）。 除了安全matrix之外，我们考虑将wiki上的内容限制在非超级秘密的内容中，但是当然这需要加以监控。 另一种解决scheme（当前）是监视视图并报告任何可疑的情况（例如，报告在两天内有2000个视图的客户站点的一个人）。 再次 – 这不是理想的，因为这并不直接暗示错误的动机。 有没有人有更好的解决scheme？ 一家公司的维基如何能够获得安全，并保持低门槛USP？ 顺便说一句，我们使用MediaWiki和Lockdown来排除一些pipe理人员。
我们有一个MediaWiki安装，并收到投诉，它变得越来越慢。 我们如何提高速度/性能？ 我有一个提示（我将在下面添加），但我真的有兴趣听到更多。 最好每个答案一个提示。
我在以下LAMP平台上安装了MediaWiki 1.16.2，该平台在16 GB RAM双处理器机器上的其他应用程序上performance相当出色：CentOS 5.7（64位）Apache 2.2.3 MySQL 5.0.77 PHP 5.1.6 这似乎取决于使用的浏览器，但是频繁地保存编辑过的页面太慢了 – 对于一个非常简单的更改来说，等待10到20秒并不less见。 渲染页面的速度非常快，但是编辑之后的保存会导致用户体验的消失。 从运行Opera的客户端比在Firefox上（在Fedora Linux平台上）编辑时，我发现了一些改进。 有关我可以在哪里调整服务器以使其更好的提示？ 在机器上运行Apache的基准是令人印象深刻的，BTW。
我们正在寻找进一步加强我们的文档的方法，以及我们能够轻松访问信息以及编辑信息的能力。 考虑到这些想法，我们创build了一个基于我们的第一层（服务台）的MediaWiki平台的内部维基。 这对服务台来说是一个巨大的成功，他们在日常运营中广泛使用。 现在，我们正在研究为我们的第2层（系统pipe理员）logging事情的方式。 由于信息的敏感性以及它将包含如何构build我们的服务器等的步骤，我们需要将方法2的信息与方法1的信息分开。 我正在寻找关于如何实现以下目标的想法和build议： 基于MediaWiki平台的集中式文档 第1层和第2层之间的分离内容 我们喜欢第一层的外观和感觉，第二层可以使用 如果我们要运行两个不同的MediaWiki安装，这可以运行在同一台服务器上吗？ 这甚至是一个好主意，在同一台机器上运行多个MediaWiki安装？ 支持每个文档安装的FQDN和SSL证书 有没有办法根据用户或组成员来分割或保留第一层MediaWiki安装的单独部分？ 预先感谢您，我期待您的意见和build议。