服务器问题集锦，包括 Linux（Ubuntu, Centos，Debian等）和Windows Server服务器
我无法在Windows 7上获得FTP服务器设置。 我已经使用控制面板 – >程序 – >打开和closuresWindowsfunction添加了该服务。 我可以看到服务已经开始在控制面板 – >服务。 但是当我启动一个Windows命令行窗口cmd ，我没有连接。 ， C:\Users\mattf>ftp localhost ftp> ls Not connected. ftp> open localhost ftp> ls Not connected. ftp> dir Not connected. ftp> quit C:\Users\mattf> 而且就我所知。 我不知道为什么这不起作用 – 它可能是防火墙设置？
我目前每晚和每周都快照我的基于ZFS的NAS，这个过程几次拯救了我的屁股。 但是，虽然快照的创build是自动的（来自cron），但删除旧快照仍然是一项手动任务。 很明显，如果我被公交车撞上了，或者没有执行手动任务，那么NAS将会耗尽磁盘空间。 有没有人有任何好的方法/脚本来pipe理存储在ZFS系统上的快照数量？ 理想情况下，我想要一个脚本遍历给定的ZFS文件系统的所有快照，并删除除该文件系统的最后n个快照外的所有快照。 比如我有两个文件系统，一个叫tank ，另一个叫sastank 。 快照用它们的创builddate命名： sastank@AutoD-2011-12-13所以一个简单的sort命令应该按顺序列出它们。 我希望保留最近2周的tank每日快照，但只有最后两天值得的快照。
当我尝试ping IP地址10.10.208.57我没有任何反应，因为在这个IP地址的networking中没有任何东西存在。 但是如果我尝试ping 10.10.208. 0 57而不是另一个IP地址响应： root@everest:/root# ping 10.10.208.057 PING 10.10.208.057 (10.10.208.47) 56(84) bytes of data. 64 bytes from 10.10.208.47: icmp_seq=1 ttl=253 time=0.732 ms 64 bytes from 10.10.208.47: icmp_seq=2 ttl=253 time=0.695 ms 64 bytes from 10.10.208.47: icmp_seq=3 ttl=253 time=0.659 ms 64 bytes from 10.10.208.47: icmp_seq=4 ttl=253 time=0.705 ms 考虑到10.10.208.47是利盟E120n打印机，这个奇怪的问题的起源可能是什么？
受这个问题的启发，我反过来问：系统pipe理员需要了解多less编程知识？ 更具体地说，什么编程工具是有用的系统pipe理员有？
我希望能够在特定时间安排服务器重新启动，但不是定期。 我怎样才能做到这一点，而无需添加和删除cron条目？
我正在CentOS.org上阅读文档 。 在第25.1.2节。 分区：把一个驱动器变成多个 ，有以下的说法： 分区表分为四个部分或四个主分区。 主分区是硬盘上只能包含一个逻辑驱动器（或部分）的分区。 每个部分可以保存定义单个分区所需的信息，这意味着分区表可以定义不超过四个分区。 我不明白为什么只能有四个分区。 这只是它在一开始就devise的方式吗？ 真的只能有4个主分区吗？
我刚刚在服务器上安装了Windows Server 2008，我可以通过远程桌面进行连接，但无法ping通。 我是否需要在防火墙上打开特殊端口才能ping通服务器？
在我正在build设的网站上，我计划logging提交的IP地址，以防万一是必要的。 我不介意代理，但彻底欺骗你的IP地址将打败目的。 要执行完整的GET操作，（不pipe您是否收到或是否通过）都是一个合法的IP地址？ 或者一个网站被垃圾邮件从随机欺骗IP地址的post？ （POST有什么不同？）
我正在寻找一个日志文件或任何服务来报告由于用户名/密码错过匹配失败的最新login尝试。 CentOS有没有这样的工具？ （内置是首选） 我的第二个问题，更一般地说，我需要一个渗透到我的服务器的日志文件。 理想情况下，这个日志应该包含所有的尝试，包括login，httpd活动和其他传统的开放端口。
postgres SELECT查询在我们的数据库服务器上失去控制，并开始吞噬大量内存并进行交换，直到服务器内存不足。 我通过ps aux | grep postgresfind了特定的过程 ps aux | grep postgres并运行kill -9 pid 。 这个过程被杀死，记忆力如预期地被释放了。 系统和postgres查询的其余部分似乎不受影响。 该服务器在SLES 9 SP4上运行postgres 9.1.3。 然而，我们的一位开发人员扼杀了我杀死一个postgres进程kill -9 ，说这将取消整个postgres服务。 事实上，事实并非如此。 我已经做了很多次，没有看到任何负面影响。 有了这个说法，并且在进一步阅读之后，看起来像没有标志的kill pid是杀死失控postgres进程的首选方法，但是在postgres社区中的其他用户，这听起来像postgres多年来“变得更好”这样在一个单独的查询进程/线程上kill -9不再是一个死刑。 有人能够启发我，以正确的方式杀死一个失控的postgres进程，以及如何使用kill -9与灾难（或良性）是Postgres这些天？ 感谢您的洞察力。