服务器管理员

系统和网络管理员的问答

6
如何释放死进程使端口保持打开状态?
我的一位同事最近遇到了一个问题,据称已死亡的进程仍然绑定到网络端口,从而阻止其他进程绑定到该端口。具体来说,netstat -a -b据报告,System以PID 4476 命名的进程的端口60001已打开,但不存在具有PID 4476的进程,至少据我所知。 进程浏览器和任务管理器未列出PID 4476(尽管还有另一个名为SystemPID 4的进程,它具有自己的一组TCP连接,其中不包括60001)。 taskkill /PID 4476还报告找不到PID 4476。 有没有办法杀死这个神秘的系统进程,以释放它当前绑定的端口?什么会导致这种情况发生?怎么会有任务管理器,进程资源管理器和taskkill不知道的进程?重新启动设法解决了这个问题,但是我想知道是否有一种方法可以在不重新启动的情况下进行修复。
63 windows  port  process  zombie 


10
如何扑灭服务器机架中的小火,以最大程度地减少对周围设备的损坏?
假设我有一个装有几个服务器和其他东西的机架。其中一台服务器严重过热,在附近有军人的情况下开始吸烟或着火。 如果在公寓中发生类似的事情,并且附近有灭火器,则应立即使用后者迅速灭火,但如果服务器机架灭火不当,可能会对周围设备造成不必要的额外损害。 澄清一下,我说的是一种很小的火灾,它可以尝试灭火而又不冒生命危险-抓住附近的灭火器,将其排出,然后在15秒钟之内灭火。 扑灭服务器机架中的局部小火有什么策略?使用哪种类型的灭火器?如何减少对周围设备的损坏?

9
如何使scp复制隐藏文件?
我经常使用SCP来复制文件-特别是与Web相关的文件。问题是,每当执行此操作时,我都无法获取复制隐藏文件的命令(例如,.htaccess)。 我通常会这样调用: scp -rp src/ user@server:dest/ 这不会复制隐藏文件。我不希望有再次调用这个(做类似的东西scp -rp src/.* ...-并且具有奇怪.和..意义呢。 我在scp手册页中没有看到有关“包括隐藏文件”的任何内容。 我该怎么做?
63 scp  files 



3
如何检查远程SMTP服务器的TLS证书?
我们有一个在Windows Server 2008上运行的Exchange 2007服务器。我们的客户端使用其他供应商的邮件服务器。他们的安全政策要求我们使用强制TLS。直到最近,这一切都很好。 现在,当Exchange尝试将邮件传递到客户端的服务器时,它将记录以下内容: 无法建立连接器“默认外部邮件”上域安全的域“ ourclient.com”的安全连接,因为对ourclient.com的传输层安全性(TLS)证书的验证失败,状态为“ UntrustedRoot”。请与ourclient.com的管理员联系以解决该问题,或从受保护的域列表中删除该域。 从TLSSendDomainSecureList中删除ourclient.com会导致使用机会性TLS成功发送邮件,但这只是暂时的解决方法。 客户是一家规模庞大,对安全敏感的国际公司。我们的IT联系人声称没有意识到其TLS证书的任何更改。我已多次要求他确定生成证书的授权,以便我可以对验证错误进行故障排除,但到目前为止,他一直无法提供答案。据我所知,我们的客户可以用内部证书颁发机构的证书替换其有效的TLS证书。 有谁知道一种手动检查远程SMTP服务器的TLS证书的方法,就像在Web浏览器中处理远程HTTPS服务器的证书一样?确定谁颁发了证书并将该信息与我们的Exchange服务器上的受信任根证书列表进行比较可能非常有帮助。

16
如何为阴影创建SHA-512哈希密码?
我之前看到的SF问题导致了产生MD5哈希密码的答案。 有没有人建议生成SHA-512哈希密码?我希望使用一个衬纸而不是脚本,但是,如果脚本是唯一的解决方案,那也很好。 更新资料 用这个替换以前的py2版本: python3 -c "import crypt;print(crypt.crypt(input('clear-text pw: '), crypt.mksalt(crypt.METHOD_SHA512)))"

1
查找系统服务的位置
在许多不同的地方可以放置systemd单位文件。仅提供服务名称,是否有一种快速简便的方法来询问systemd从哪里读取服务的声明?
62 systemd 

2
当我有uWSGI时为什么需要nginx
我想部署Django应用程序时,有很多教程介绍如何配置nginx与uWGSI合作。 但是,为什么我需要此套件中的nginx?uWSGI本身可以服务WSGI Python应用程序,它可以服务静态文件,也可以服务SSL。nginx可以做哪些uWSGI无法做的事情?
62 nginx  django  uwsgi 

8
磁带机的优点是什么?
IBM至今仍在开发和销售磁带机。它们的容量似乎可以与当今的硬盘驱动器相提并论,但是搜索时间和传输速率都大大低于硬盘驱动器。 那么,什么时候磁带驱动器比硬盘驱动器(或SSD)更好呢?

10
如何[礼貌地?]告诉软件供应商他们不知道他们在说什么
但这不是一个技术问题,而是一个有效的问题。场景: HP ProLiant DL380 Gen 8,带有2个8核Xeon E5-2667 CPU和256GB RAM,运行ESXi 5.5。给定供应商系统的八个VM。用于测试的四个VM,用于生产的四个VM。每个环境中的四个服务器执行不同的功能,例如:Web服务器,主应用程序服务器,OLAP DB服务器和SQL DB服务器。 已配置CPU份额,以阻止测试环境影响生产。所有存储在SAN上。 我们对性能有一些疑问,供应商坚持认为我们需要为生产系统提供更多的内存和vCPU。但是,从vCenter可以清楚地看到,现有分配没有被触及,例如:主应用程序服务器上CPU使用率的每月视图徘徊在8%左右,奇数峰值高达30%。峰值往往与备份软件的启动相吻合。 RAM上的情况与此类似-服务器上的最高利用率约为35%。 因此,我们一直在使用Process Monitor(Microsoft SysInternals)和Wireshark进行一些挖掘,我们建议该供应商首先对它们进行一些TNS调整。但是,这不是重点。 我的问题是:我们如何让他们确认我们发送给他们的VMware统计数据足以证明更多的RAM / vCPU无效? -更新2014年12月7日- 有趣的一周。我们的IT管理层表示,我们应该更改VM分配,现在我们正在等待业务用户的一些停机时间。奇怪的是,业务用户说应用程序的某些方面运行缓慢(与我所不知道的相比),但是当我们需要关闭系统时,他们会“让我们知道”(抱怨) ,发牢骚!)。 顺便说一句,系统的“慢”方面显然不是HTTP(S)元素,即:大多数用户使用的“瘦应用” 。听起来像是主要财务机构使用的“胖客户端”安装,显然“速度较慢”。这意味着我们现在正在调查中考虑客户端和客户端-服务器的交互。 由于该问题的最初目的是寻求帮助,是沿着“戳”路线,还是只是进行更改,而我们现在正在进行更改,因此,我将使用longneck的答案将其关闭。 谢谢大家的意见; 像往常一样,serverfault不仅仅是一个论坛-就像心理学家的沙发:-)

1
为什么我的XFS文件系统突然占用更多空间并充满稀疏文件?
我已经在各种Linux服务器上将XFS文件系统作为数据/增长分区运行了近10年。 我注意到最近运行6.2+版本的CentOS / RHEL服务器出现了一个奇怪的现象。 从EL6.0和EL6.1迁移到较新的操作系统版本后,稳定的文件系统使用变得高度可变。最初安装有EL6.2 +的系统表现出相同的行为。显示XFS分区上磁盘利用率的剧烈波动(请参见下图中的蓝线)。 之前和之后。从6.1升级到6.2是在星期六进行的。 同一系统上一季度的磁盘使用情况图,显示了上周的波动。 我开始检查文件系统中是否有大文件和失控的进程(可能是日志文件?)。我发现最大的文件报告了与du和不同的值ls。du有无--apparent-size开关运行说明了差异。 # du -skh SOD0005.TXT 29G SOD0005.TXT # du -skh --apparent-size SOD0005.TXT 21G SOD0005.TXT 使用ncdu实用工具对整个文件系统进行快速检查得出: Total disk usage: 436.8GiB Apparent size: 365.2GiB Items: 863258 文件系统中充满了稀疏文件,与先前版本的OS /内核相比,丢失了将近70GB的空间! 我仔细研究了Red Hat Bugzilla并更改日志,以查看是否有关于XFS的相同行为的报告或新公告。 娜达 升级期间,我从内核版本2.6.32-131.17.1.el6转到了2.6.32-220.23.1.el6;次要版本号无变化。 我使用该filefrag工具检查了文件碎片。XFS分区上一些最大的文件具有数千个扩展区。在xfs_fsr -v活动缓慢的情况下运行联机碎片整理有助于暂时减少磁盘使用(请参见上方第一张图表中的周三)。但是,一旦系统活动繁忙,使用率便迅速增加。 这是怎么回事


5
Ubuntu上SSL证书和私钥的最佳位置
在Ubuntu上,看起来似乎是用于签名证书(供nginx使用)的私钥的最佳位置。 /etc/ssl/private/ 这个答案补充说证书应该放进去,/etc/ssl/certs/但这似乎是不安全的地方。是否.crt需要保护文件安全或将其视为公开文件?

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.