我花了很多时间为那些IT专业人员很less，或者没有全职员工处理常见问题的公司进行邮件迁移。 因此，从来没有制定电子邮件使用和最佳stream程的政策。 这些环境中的最终用户是非技术性的，倾向于抵制变化。 我完全理解更改/移动/升级邮件平台的机制。 在大多数情况下，我协助企业从基于Linux的POP3或IMAP迁移到Microsoft Exchange。 这种types的移动暴露了大量的用户不良习惯。 我关心的并不是我过去遇到的电子邮件囤积问题涉及的磁盘空间， 每个公司都有一个 这是关于我与一家特定公司合作时常见的问题和弊端。 在上次迁移期间，我看到： 用户CC:他们自己在每封电子邮件（大概是作为一种方式来跟踪消息线程？）。 已发送邮件文件夹中的300兆字节邮件 ？！？ 发送Outlook的人在每个发出的消息上都读取收据。 维护与其对应的每个联系人的子文件夹的用户。 有时手动。 有时客户端规则非常糟糕。 过度组织子文件夹 。 （一些文件夹中只有一条消息）。 收件箱下的子文件夹（我不确定这是不是一个坏习惯，但感觉不对）。 无偿使用优先标志。 一切都很 重要！ 已发送邮件文件夹中有4年以上的电子邮件。 收件箱中的25,000个或更多项目（其中大部分未读）。 “ 已删除邮件”文件夹中有15,000个或更多邮件 。 在“草稿”文件夹中有24,000个项目的用户！ （错误的客户端规则的结果）。 自动档案越来越失控。 这是怎么发生的？ 电子邮件是比较新的，用户没有教育如何使用它？ 这是一个用户界面的问题，其中删除项目文件夹只是一个一键归档系统？ pipe理员没有尽力帮助正确的行动？ 如果用户在使用基本电子邮件时遇到问题，我该如何解决教他们关于外出回复以及如何工作群组日历（gulp）的挑战？ 我的问题是，是否有一套关于如何pipe理电子邮件的标准指南？ （甚至是一本小册子？） 用户的教育问题往往会减慢这些部署，因为我正在通过各种方式改变人们已经到达的工作stream程。 当这影响组织的各个层面/angular色的人们时，似乎没有标准。
我们正在为我们的基于RHEL / RHEL的服务器执行自动更新。 最初的想法：使用Puppet，我们禁用默认存储库并指向我们自己的。 然后，我们使用ensure => latest作为我们想要自动更新的包。 问题：我们看到有些服务在更新后重新启动（duh）。 问：有没有人对如何更好地自动化Linux更新和减轻服务自动重启的策略有任何build议？ 我们更喜欢包含Puppet的解决scheme，但是，如果我们需要使用其他服务，那不是一个破坏交易的方法。 编辑 可能的解决scheme：我提交了一个解决scheme，实现了许多@ voretaq7和@ewwhitebuild议的内容。 看来这就是我现在要走的路线。 如果您有其他build议，请发表评论或提交答案。
我正在使用Puppet为参数化的类提供MySQL： class mysql::server( $password ) { package { 'mysql-server': ensure => installed } package { 'mysql': ensure => installed } service { 'mysqld': enable => true, ensure => running, require => Package['mysql-server'], } exec { 'set-mysql-password': unless => "mysqladmin -uroot -p$password status", path => ['/bin', '/usr/bin'], command => "mysqladmin -uroot password $password", require => Service['mysqld'], […]
我一直在试图把一个基本的服务器iptables脚本放在一起，这个脚本可以在大多数使用HTTP（S）和SSH（端口80,443和22）的网站上运行。 毕竟，大多数VPS只需要这些起始端口规则，并可以根据需要添加邮件或游戏端口。 到目前为止，我有以下规则集，我想知道是否有人知道更好的脚本或可以添加的任何改进。 *filter # Allows all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0 -A INPUT -i lo -j ACCEPT -A INPUT ! -i lo -d 127.0.0.0/8 -j REJECT # Accepts all established inbound connections -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT # Allows all outbound traffic # […]
我知道它已经永远得不到正式的支持，但是我已经看到或听说过许多同时运行AD DS和Exchange的单一主机的小型企业安装。 对于一个资源匮乏的小企业来说，节省是令人信服的。 所以假设我们知道用户需求不会超过25个用户，比如10个用户， 现在在同一台计算机上运行Exchange和AD DS的真正“坏”现象是什么（没有任何types的虚拟化） ？ 有什么特别坏的呢？ （除了“微软这么说”之外，还要记住前两个最重要的原因） 如果有的话，可以采取什么措施来缓解“坏”的问题？ 您可以假设有问题的业务是： 有一个合理的商业ISP或一个单一的物理现场服务器 有一个已经挖掘出来的虚拟资源池，他们不想花费更多。 我想到的情况是第二种情况，只有一个虚拟机可能成为添加Exchange的候选者，因为它是唯一的Windows虚拟机，并具有足够的超额内存来实现。 无论如何，这个推理可能并不是那么的合理，但是让我们说这些是你必须要处理的限制。
对于那里的IT经理来说，这是一个普遍的pipe理问题。 我们是一个小公司，在我们的colo cabinent有大约4台服务器。 没有全职的IT经理。 但是我们每个月都有一个合同人，我正在分享这些计划的实际可怕时间。 我相信他有一个计划（可能在他的脑海里..），但是如果他被巴士撞到，我们就不好。 你们怎么处理这个？ 他是很久以前的朋友，但是我担心这对我们来说是长期的危险..我曾经多次面对他，他告诉我不要担心，他已经把它覆盖了。 谢谢。
我是托pipe公司的pipe理员，我主要处理Linux机器，尽pipe我们有很多Windows服务器客户。 以我的身份，我只使用SMB作为本地局域网上的文件/打印服务器。 有没有理由离开SMB？ 我没有听说有任何真正的理由让它暴露在互联网上，有没有Windows的东西，我不知道这需要它？
在我工作的办公室，IT员工的其他三名成员随时都使用域pipe理员组成员的帐户login到他们的计算机。 我对使用pipe理员权限（本地或域）login有严重的疑虑。 因此，对于日常的计算机使用，我使用一个只有普通用户的账户。 我也有一个不同的帐户，是域pipe理员组的一部分。 当我需要在计算机，其中一台服务器或另一台用户的计算机上执行某些需要提升的权限时，我才使用此帐户。 这里最好的做法是什么？ networkingpipe理员是否应该一直login到整个networking（甚至是本地计算机）呢？
就在最近，我有一个开发人员不小心尝试将数据库恢复到生产阶段，而他应该将其恢复到临时副本。 考虑到数据库名称是相似的，即CustomerName_Staging和CustomerName_Production很容易做到。 理想情况下，我会把这些放在完全独立的盒子上，但是这样做成本过高，严格来说，如果用户连接到错误的盒子，就不会阻止同样的事情发生。 这本身并不是一个安全问题 – 它是使用临时数据库的正确用户，如果在生产数据库上有工作要做，那也是他自己的工作。 我希望有一名部署人员将这些担忧分离出来，但是这个团队还不够大。 我很想听听一些关于如何防止这种情况的练习，configuration和控制方面的build议。
我们去年从我们的托pipe服务提供商处收到了一封关于我们的某个帐户的电子邮件，它已经被妥协并用于提供相当丰厚的垃圾邮件帮助。 很显然，用户已经重置了她的密码来改变她的名字（姓氏是你可能第一次猜到的东西）。她在一周之内迅速被黑客入侵 – 她的账户发出了大量的27万封垃圾邮件，而且非常快受阻。 到目前为止，没有什么特别的。 那个会发生。 您可以将密码更改为更安全的密码，然后教育用户并继续前进。 然而， 更令我担心的是，我们的一个账户已经被妥协了。 我们的托pipe服务提供商为了提供帮助，实际上在以下电子邮件中引用了我们的密码 ： 我感到惊讶。 我们很快就要续签合同了，这感觉就像一个破产者。 托pipe服务提供商能够find账户中使用的实际密码的常见程度如何？ 大多数托pipe服务提供商是否有一个账号滥用部门，比前线代表拥有更多的访问权限（如果需要，可以查找密码），还是这些人没有按照最佳做法让他们的任何员工访问用户密码？ 我以为密码应该是散列，不可检索？ 这是否意味着他们以纯文本存储每个人的密码？ 托pipe服务提供商是否能以这种方式发现账户密码是合法的 ？ 对我来说这似乎太不可思议了。 在我们考虑不断变化的提供者之前，我希望得到一些保证，这不是通常的做法，而且我们的下一个托pipe提供者也不可能把事情设置成相同的方式。 期待听到你的意见。