服务器 Gind.cn

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

通过SSH隧道连接时,MySQL访问被拒绝错误

几个月来,我一直通过SSH隧道连接到运行在本地testing服务器上的MySQL实例,没有任何问题。 突然之间,没有任何变化,我可以想到,服务器已经开始拒绝来自Sequel Pro的login尝试,错误是: 无法连接到主机127.0.0.1,因为访问被拒绝。 仔细检查您的用户名和密码,并确保您的当前位置的访问是允许的。 MySQL说:拒绝访问用户'root'@'localhost'(使用密码:是) 当通过SSH直接连接到服务器时,我可以通过terminallogin,而不是通过SSH隧道。 这个问题并不是特定于Sequel Pro或者仅仅是我自己,当通过MySQL Workbench连接时,和其他人一样,我也遇到同样的错误。 为了理智,我已经用mysqladmin重置了密码,这绝对不是问题。 当我开始研究它时,我发现错误是将服务器报告为“localhost”,而不是我在Sequel Pro中input的“127.0.0.1”。 一个朋友build议这可能只是错误的处理,但似乎很奇怪,因为本地主机和MySQL中的127.0.0.1之间的显着差异。 为了解决隧道问题,我授予对root @%的访问权限,以便我可以直接连接。 这大部分工作,我可以查看表数据,创build新的数据库等。唯一的问题是,当我来创build用户我得到的错误: 访问拒绝用户“root”@“%”(使用密码:是) 奇怪的是用户实际上是创build的,我认为这只是一个授权问题。 虽然如此,从terminal我可以做任何事情,当以root身份login。 任何人都可以帮助揭示为什么隧道连接和(可能)授予命令正在接收拒绝访问错误? 为了参考,MySQ版本是5.6.16,主要是默认设置,通过MAC OS X Server机器上的Homebrew安装。 更新 以下是根目前被授予访问权限的主机列表: mysql> select host,user from mysql.user where user='root'; +—————-+——+ | host | user | +—————-+——+ | % | root | | 127.0.0.1 | root | | ::1 | root […]

如何创build比SHA-1更强的自签名证书?

对于开发环境,我可以在IIS7.5中创build创build自签名证书。 但是该证书是SHA-1,最近浏览器正在抱怨。 当我打开FireBug时,我看到以下警告: “该站点使用SHA-1证书;build议您使用带有使用比SHA-1更强的散列函数的签名algorithm的证书。” 所以我的问题是: 1)是否有办法创build比SHA-1更强的自签名证书? 2)如果没有,有没有办法告诉浏览器停止显示这些警告? UPDATE 我结束了使用@vcsjones的答案,但那只是我到目前为止。 在这之前,我们需要解决一些问题,然后才能开始工作。 1)出于某种原因,我无法使用密码导入证书。 所以我最终创造了一个没有。 2)当我通过IIS导入.pfx证书时,当我尝试在“编辑绑定”中应用新证书时,我不断收到“指定的login会话不存在”。 所以我做了很less的研究,发现这个答案是有用的,特别是Mike L的答案。 另外我要补充的是,当你导入证书时,请记得select.pfx证书。 导入向导的默认select是* .cer,您可以导入(我犯的错误),但是我无法在IIS服务器证书中看到证书。 当我向近处看时,图标中缺less一​​点钥匙。 现在,我研究了,我能够通过KB-889651文章修复它。 所以请确保您导入.pfx,它将无需修复。 另请注意,如果您对此证书有信任问题,请将其导入“受信任的根证书颁发机构”。

Windows 10:组策略启动后无法直接应用,稍后成功

我的问题是组策略不适用于客户端刚引导时。 直接引导后,客户端在源“GroupPolicy(Microsoft-Windows-GroupPolicy)”事件日志和事件ID 1058:“组策略处理失败[…]”的事件日志中发布错误消息。 在Details选项卡中,ErrorCode是50,代表ERROR_NOT_SUPPORTED。 这不仅仅是一个表面上的问题:这些策略确实没有得到正确应用:例如,映射的networking驱动器不在那里。 等待一段时间后,执行“gpupdate”工作,策略正常应用:映射的networking驱动器出现。 我能够重现该问题的最简单的情况:在新安装的Windows Server 2012 R2上新创build的域,客户机是新安装的Windows 10 64位机器。 该域由一个域控制器组成,与其他域没有任何关系。 由于错误消息指出Windows无法从域的Sysvol共享中读取.GPT文件,我试图从命令提示符访问相同的文件。 事实上,当我开机后立即打开一个命令提示符,我得到这个: C:\Users\username>dir \\domain.example.com\sysvol The request is not supported. 等待一两分钟后,执行相同的命令会给出一个目录列表。 在这一点上运行gpupdate将会正常工作。 我没有设置组策略设置“始终等待networking在计算机启动和login”为“已启用”,并且我知道这个策略是适用的:在同一个策略对象中指定了一个registry设置,当我检查registry在客户端指定的设置在那里。 其他可能相关的因素: NTLM在域中受到限制,但这似乎并不重要:即使在启用它之后,更新策略并重新启动所有机器,症状仍然相同。 服务器是使用DHCP还是使用静态configuration来configuration并不重要。 域的DNS服务器不支持dynamic更新。 必要的logging手动添加(从C:\ Windows \ System32 \ config \ netlogon.dns) hibernate状态在客户端被禁用(使用powercfg /h off ),因此每次启动都是完全启动,而不是快速启动 策略启动策略处理等待时间设置为120秒 与DC的连接正常工作。 坪将工作。 closures客户端,在AD中禁用我的帐户,打开客户端将导致客户端不能login我的帐户:它会立即注意到帐户被禁用。 除了这个问题,我没有注意到任何不寻常的事情。 这似乎是一个中小企业问题比组策略问题。 在服务器端嗅探连接显示了一些有趣的事情:第一次执行命令dir \\domain.example.com\sysvol ,DC上的Microsoft Message Analyzer中显示以下内容: 客户端build立到DC的端口445的TCP连接,并且成功执行ComNegotiation(DialectRevision:0x02FF)。 紧接着,一个谈判成功执行。 DialectRevision是0x0302。 […]