服务器 Gind.cn

服务器问题集锦,包括 Linux(Ubuntu, Centos,Debian等)和Windows Server服务器

木偶或厨师提供什么优势/特点超过盐(反之亦然)?

我正在考虑推出新的configurationpipe理工具来取代我们自己开发的解决scheme。 事实上的标准是Chef和Puppet,它们都是以Ruby为中心的(尽pipe可以用来部署非Ruby环境)。 我们绝大部分的开发工作都是在Python中完成的,我们的内部部署工具大量使用Fabric 。 所以我正在向Salt学习,因为它也是Python,尽pipe它不像Chef或Puppet那么成熟。 但是由于我对选项不够熟悉,我发现很难比较苹果与苹果。 除了较小的社区,我是否会放弃使用Salt而不是木偶/厨师? 更新 我发布这个问题已经有六个月了。 尽pipe它已经被closures了,但已经被看了1000多次了,所以我想我会评论一下我的经验。 我最终决定了Puppet,因为它有一个更大的社区。 然而,这是一个非常令人沮丧的经验,主要是由于令人费解的Puppetconfiguration语法。 由于我现在有一个比较两个参考的框架,我最近再次看看盐 – 我不回去。 这是非常非常酷的。 我最喜欢的东西: 推拉式configuration模型的无缝集成。 木偶使用拉模式(节点定期轮询服务器更新),并有一个名为木偶的姐妹组件推动变化。 两者对我都很重要,我更喜欢Salt的工作原理。 当你有很多的节点时,Salt也会执行得更快。 configuration语法使用YAML,这是一个简单的文本格式,使用缩进和项目符号点。 您也可以select通过模板使用其他configuration格式。 根据我的经验,这使得盐约10倍容易学习和维护。 基于Python的。 这是我首先看到Salt的最大原因。 它最终成为我留下的一个更小的原因。 但是,如果您是像我们这样的Python商店,那么开发Salt插件会更容易。

“dd”中的“bs”选项是否真的提高了速度?

我时不时地被告知,为了提高“dd”的速度,我应该仔细select一个合适的“块大小”。 即使在这里,在ServerFault上,别人写道 :“ …最佳块大小是依赖于硬件的… ” (iain)或“ …完美的大小将取决于您的系统总线,硬盘控制器,特定的驱动器本身,以及每个人的驱动程序…… “ (chris-s) 由于我的感觉有点不一样( 顺便说一下,我认为深度调整bs参数所需的时间远远高于收到的收益,就省时而言,默认值是合理的 ),今天我刚去通过一些快速和肮脏的基准。 为了降低外部影响,我决定阅读: 从一个外部MMC卡 从一个内部分区 和: 与相关的文件系统未被占用 将输出发送到/ dev / null以避免与“写入速度”相关的问题; 避免了HDDcaching的一些基本问题,至less在涉及HDD时。 在下表中,我报告了我的发现,用不同的“bs”值读取1GB的数据( 你可以在这个消息的最后find原始数据 ): 基本上是这样的: MMC:有一个bs = 4(是!4字节),我达到了12MB / s的吞吐量。 从bs = 5及以上得到的最大值为14.2 / 14.3; 硬盘:有一个BS = 10我达到了30 MB /秒。 肯定低于默认的bs = 512得到的95.3 MB,但是…也很重要。 另外,CPU系统时间与bs值成反比是非常明显的(但是这听起来是合理的,因为bs越低,由dd产生的系统调用的数量越高)。 说完所有上述内容,现在的问题是:有人可以解释(内核黑客?)这种吞吐量中涉及的主要组件/系统是什么,如果真的值得指定高于默认值的bs, MMC案例 – 原始数字 BS = 1M root@iMac-Chiara:/tmp# time […]

被黑客入侵。 想了解如何

有人第二次在我帮助运行的网站上附加了一段javascript。 这个javascript劫持谷歌的AdSense,插入自己的帐号,并坚持广告。 代码总是附加在一个特定的目录(一个由第三方广告程序使用的目录),会影响这个广告目录(大约20个)内的多个目录中的文件数量,并且在大致相同的时间插入时间。 AdSense帐户属于中文网站(位于一个小镇,不到一个小时,我将在下个月到中国),也许我应该去破坏头…开玩笑,顺便说一下),顺便说一句…这是关于该网站: http : //serversiders.com/fhr.com.cn 那么,他们如何将文字追加到这些文件呢? 它与文件上设置的权限有关(从755到644)? 对于networking服务器用户(这是MediaTemple所以它应该是安全的,是吗?)? 我的意思是,如果你有一个权限设置为777的文件,我仍然不能随意添加代码…他们怎么可能这样做呢? 下面是一个实际的代码为你的观看乐趣的样本(正如你所看到的…没有太多的东西,真正的诀窍是他们如何得到它): <script type="text/javascript"><!– google_ad_client = "pub-5465156513898836"; /* 728x90_as */ google_ad_slot = "4840387765"; google_ad_width = 728; google_ad_height = 90; //–> </script> <script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script> 由于许多人已经提到它,这里是我已经检查(通过检查我的意思是我周围的时间文件修改任何古怪的时间,我grepped文件的POST语句和目录遍历: access_log(除了正常(即过度)的msn botstream量) error_log(没有什么,但通常的文件不存在无害的外观文件错误) ssl_log(只是平时的) messages_log(在这里除了我以外没有FTP访问) *更新:**好的,解决了。 来自中国的黑客已经在我们的网站上放置了一个文件,允许他们执行各种pipe理事务(数据库访问,删除和创build文件和目录,你可以命名它们可以访问)。 我们很幸运,他们没有做更具破坏性的事情。 在正常的apache日志文件中没有任何东西,但是我在Web服务器日志分析器中发现了一组不同的日志文件,证据就在那里。 他们用自己的pipe理员用户名和密码访问这个文件,然后在服务器上编辑他们需要的任何东西。 他们的文件有“apache”作为用户,而我们网站上的所有其他文件有不同的用户名。 现在我需要弄清楚他们是如何将这个文件物理地传到我们的系统上的。 我怀疑这个问题最终会归于我们的networking主机(Media Temple),除非他们真的有我们的FTPlogin…不知道我将如何确定,但是,因为这个文件可能已经有一段时间了。