服务器 Gind.cn

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

我可以将OS X资源分支存储在Samba共享位置,而不是在dotbar文件中吗?

OS X资源分支是附加到常规文件的备用数据stream。 它们可能包含文件的自定义图标,彩色标签,关键字或由用户或应用程序设置的任何其他元数据。 它们本地支持OS X的HFS +文件系统,但是每当OS X挂载另一个文件系统时,无论本地(FAT32)还是远程(NFS,SMB),它们都存储在所谓的“dotbar”文件中:资源分支为常规文件name.ext存储在另一个常规但隐藏的文件._name.ext 。 (它们不能与.DS_Store文件混淆,它们存储目录的视图设置,例如图标与列视图或其窗口的位置。) dotbar ._文件的问题在于,它们是目标文件系统中的实际常规文件,具有与原始文件相同的扩展名,因此以多种方式造成严重破坏。 例如,Ant和Maven会将._MyClass.java作为另一个Java文件进行编译。 我发现可以将OS Xconfiguration为在SMB命名stream中存储资源分支,并且可以将Sambaconfiguration为将命名stream存储在POSIX扩展属性中,或者也可以将其存储在 别处的软件仓库目录中 。 这两个解决scheme将解决dotbar文件污染目标文件系统的问题,但我不能得到任何工作。 XATTR 首先我试着用xattr: vfs objects = streams_xattr kernel oplocks = no 后面的选项是由于这个错误 。 我告诉OS X使用它,通过在共享的根目录中进行,在安装之前: touch .com.apple.smb.streams.on 但是当我试图用Finder复制文件时,我得到这个错误: Finder无法完成操作,因为“hello.java”中的某些数据无法读取或写入。 (错误代码-36) 仓库 然后我试着用仓库: vfs objects = streams_depot 将.com.apple.smb.streams.on留在共享的根目录中。 试图用Finder复制相同的文件,我得到了另一个错误: 由于发生意外错误,操作无法完成 (错误代码-50) 我如何使OS X与这两个选项中的任何一个一起工作? 我的目的是从共享目录中得到那些讨厌的。 我试图简单否决dotbar文件: veto files = /._*/ delete […]

结合SharePoint和数据库镜像

这不是一个我该怎么做的问题,只是为了设置舞台。 这是你有什么经验? 在快速回复之前,请仔细阅读整个问题。 我昨天花了一天的时间教导SharePoint MCM(微软authentication大师 – 请看这里 )的学生所有关于SQL Server中的高可用性技术,以及SQL日志/恢复/备份/恢复如何工作。 这是非常重要的,因为每个企业级的MOSS安装都是隐藏起来的Entreprise级SQL Server,通常没有DBA。 Kimberly在星期五教他们一天的数据库维护(一种SQL MCM第一周缩减版)。 我们正在讨论使用数据库镜像为SharePoint数据库提供高可用性的可能性,以及相对的优缺点。 现在,我知道数据库镜像的内部深度最低,因为我曾经在微软拥有它,所以不需要在回复中指出行为和特质。 我也知道来自SharePoint人员的白皮书中的各种警告和指导原则,是的,他们只是通用的指导方针而不是硬性规定。 我的问题是这样的:我希望听到任何实施SharePoint的数据库镜像的人,以及是否发现它适用于您,或者您崩溃和烧毁。 特别是,您是如何find故障转移行为为您工作的? 你是否在一台服务器上有一些数据库负责人,另一些人是否有效地分割了你的服务器,并使其无法使用,直到手动干预将所有事情都转移到一台服务器上? 你使用它为本地或远程HA? 等等。 任何回复都将受到感谢,并将有助于拓宽与这两种技术结合的知识库,并将故事情节回馈到SharePoint产品组以及我所教授的未来MCM轮换。 谢谢! [编辑:PS我会在这个周末也把关于经验和指导方针的博客文章放在一起]

为什么vCenter 5.1u1将主机从维护模式退出?

此vCenter服务器刚刚升级到5.1更新1.我正在通过主机和固件更新,然后从各种版本的5.0升级到5.1u1。 vCenter 5.1u1似乎有一个有趣的新行为:当它们在断开连接后重新连接时,将主机从维护模式中删除 – 但非常不一致,在〜25-30主机重新启动时,我已经看到它可能是4或5次。 我只看到它发生在尚未升级到5.1的5.0主机上。 在该映像中,我将主机置于维护模式,并将其重新引导至HP SPP DVD的自动更新模式。 在通常的~40分钟的更新过程之后,主机回到了在线状态。并且在logging主机重新连接之前7秒,vCenter已经向主机发送了一个任务以退出维护模式。 根据我的理解,唯一一次vCenter将主机退出维护模式的时机是vCenter本身将其置于维护模式(例如VUM升级任务)的时间。 为什么这个vCenter将单方面从用户启动的维护模式退出主机? 编辑,附加信息: 我同时在5台主机上运行固件升级。 其中两个重新连接后退出主线模式,三个没有。 那些退出maint模式的共同因素似乎是他们离线了多久 ; 那几个试图启动到虚拟媒体的两个就是两个被淘汰的maint模式。 esx31(上图): 45分钟无响应 esx19(已退出主线): 87分钟无响应 esx24(留在maint):32分钟没有反应 esx29(留在maint):39分钟没有反应 esx32(留在maint):30分钟没有反应 esx34(已退出主线): 70分钟无响应 编辑:断开时间的想法似乎是一个红色的鲱鱼,因为它不是一直发生。 此外 ,在vpxd.log ,退出vpxd.log模式任务启动似乎总是紧随此vim.EnvironmentBrowser.queryProvisioningPolicy SOAP调用。 这里是线条,为了清晰起见, 15:27:49.535 [info 'vpxdvpxdVmomi'] [ClientAdapterBase::InvokeOnSoap] Invoke done (esx31, vim.EnvironmentBrowser.queryProvisioningPolicy) 15:27:49.560 [info 'commonvpxLro'] [VpxLRO] — BEGIN task — esx31 — HostSystem.exitMaintenanceMode — 请注意,在没有得到退出任务的节点上,仍会发生vim.EnvironmentBrowser.queryProvisioningPolicy事件。 在重新连接过程之前或之后,除了退出维护模式引起的额外事件之外,我没有看到任何其他事件的差异。 […]