服务器 Gind.cn

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

了解在IIS8上访问UCC证书的XP用户

我有一个单一的IIS网站,主办3个不同的网站,都使用相同的UCC SSL证书。 (我的网站的代码检查主机头本身,以决定哪个网站的变化显示)。 我已经修复了我的XP上的Internet Explorer用户的最致命的错误,那就是禁用IIS中的“要求主题名称指示”字段。 由于当XP用户切换到HTTPS时,如果启用了SNI,他们基本上会在没有任何警告的情况下被踢出网站(不要告诉我的老板)。 所以我完全明白,当一个用户通过HTTPS访问这三个站点中的任何一个共享同一个IP时,他被发送到同一个IIS站点并且服务于UCC证书。 即使XP支持UCC / SAN证书,以便客户端接受证书并按预期显示站点。 现在…忘记所有这些,并考虑第二个非假设的情况。 让我们假装我有两个网站: cats.com和dogs.com 他们是不同的网站,并部署在IIS 8中的两个不同的网站。 他们都在同一个UCC SSL证书* SNI被禁用 它们都绑定到相同的IP地址 现在考虑XP用户访问https://cats.com 以下是我理解事情的工作方式: DNS给浏览器返回我的IP – 可以说1.2.3.4 一个HTTPs连接被协商,但是因为XP不知道关于SNI的任何事情,它不是发送一个SSL主机头(或者他们被称为),而是通过IP访问安全站点。 所以IIS会查找与https网站绑定关联的IP,并且实际上会find两个。 比方说,IIS决定只是为您提供第一个 – 所以它给你你所期望的cats.com 。 所以没关系 但可以说,你去https://dogs.com – 你不应该实际上服务的网站cats.com因为XP上的SSL不知道SNI的SSL连接,反正它在IIS中被禁用? 那么你不。 你得到dogs.com。 我已经试过了, cats.com和dogs.com都是从Windows XP Internet Explorer 8客户端运行的。 我只是不明白为什么这个工作。 我会期待这种行为只在我的第一种情况下,当他们都共享一个IIS应用程序。 我最好的猜测是IIS 8正在接收主机头,而且足够聪明,可以将其路由到正确的网站,并find一个UCC证书名称。 那是怎么回事? 有人能进一步解释吗? *只是故意烦扰技术头脑的猫和狗主人;-)

用本地冗余分发网站文件

因此,我们正在考虑将我们的单个专用服务器(如共享虚拟主机设置)迁移到具有多个负载平衡前端服务器和独立数据库服务器(由于stream量增长和可用性问题)的体系结构。 TLDR; 当文件服务器出现故障时,我想要一些故障转移到站点文件的本地只读镜像。 场景: 大约200个虚拟主机,每个都有一些别名 每个站点基本上只有一个“包装器”,大约只有30个本地文件,大部分只是模板文件,其余的只是从一个集中的代码库 站点基本上是只读的,除了一个caching目录(可以在每个主机上分开) 没有第三方访问站点文件(即不共享) 每个网站只能获得2-10k次点击/月 目标/要求: 对任何单个服务器进行维护或由于错误而处于脱机状态时,都要具有适应性 定期进行less量文件更新的一些集中方式(手动,只是正常的站点更新),最好通过FTP 在最多5秒内将更改传播到前端服务器是可以接受的 如果一台服务器意外脱机,我会很高兴最多10分钟的文件更改丢失 在这个阶段,我们可能只会看到两台全时运行的前端服务器,另外还有一台文件服务器 可能会在AWS上实施 更多的前端服务器可能会定期添加和删除 我意识到一个典型的方法是通过版本控制进行部署,这是我们在某些情况下已经做的,但是我们的工作人员(非开发人员,主要pipe理横幅,文本更新等)非常适用于“FTP”工作stream程,我想改革,但也许还没有。 以下是我提出的解决scheme: rsync部署 文件服务器承载可通过FTP访问的站点文件的“主”副本,并通过rsync服务器公开这些副本。 我有某种“部署”接口触发每个前端服务器rsync站点和“部署”。 优点 很简单 在文件服务器上允许“暂存”版本,这可能是有用的 每个前端服务器都有自己的文件副本,如果文件服务器处于脱机状态,则不会有任何问题 缺点 有多可靠? 可能会混淆已部署的内容以及未部署的内容 NFS 具有本地caching​​的NFS文件服务器,定期rsync本地备份,然后可能通过将绑定的挂载点切换到本地备份进行故障转移。 优点 可能支持写作(不是必要的) NFS在某种程度上更简单 除非发生停电,否则应始终保持同步 缺点 我不确定本地NFScaching的效果如何,以及是否会自动使修改对象的caching无效。 没有本地caching​​NFS很慢? 我非常确定,我需要一些心跳才能触发故障切换,并在主机恢复联机时挂载主机 Gluster等 我对这个选项并不是很熟悉,但是我相信当你拥有大量的服务器时,这是一种常见的方法。 我看了一些文档,可能是合适的,但是我没有看到很多人推荐这么小规模的文档。 优点 会允许读写 支持caching我认为,应该比非cachingNFS更快? 自动复制,恢复和故障转移 缺点 我喜欢有一个可以快照和备份的单个“主”卷的想法,我不认为有一个选项可以在gluster中说“这个节点必须有一个完整的副本”。 有了这么小的服务器池,似乎你可能很容易意外地终止了两台服务器,而这两台服务器恰好有一些数据的副本 所以,我的问题是: NFS真的是我唯一的select吗? 我应该考虑其他select吗? 这些选项中的哪一个最适合我的需求? 编辑: 感谢你们的回应,我开始意识到,考虑到我的需求规模(相对较小),我正在把事情变得太复杂。 […]