我有一个脚本化的Jenkinsfile在我们的分布式Jenkins构建环境中运行。
我在Jenkinsfile中有执行Kerberos身份验证的代码。该代码基于两个小型Java程序，均已成功通过Kerberos身份验证。这两个Java程序都可以在Windows工作站和Linux虚拟机来宾上运行。
也就是说，我有一对有效的Java程序，它们使用一组Kerberos配置文件从Windows和Linux成功执行了Kerberos身份验证。当我将代码转换为Jenkinsfile时，它显然在第1步失败：找到精心构建的krb5.conf（和login.conf）文件。
Kerberos代码在正确配置的全局共享库中。我知道它已正确配置，因为该库已在我的Jenkinsfile中的其他地方使用，并且我知道它已从我们的存储库中下载了正确的Kerberos库，因为我没有得到任何类型的编译或找不到类的错误。
具体的错误消息，我没有设法让数十种不同的版本产生，而是试图将krb5.conf文件放到我认为詹金斯可能会寻找的任何地方，是这样的：
GSSException: Invalid name provided (Mechanism level: KrbException: Cannot locate default realm)
是的，堆栈跟踪的时间更长，但是如果您知道发生了什么，那么这就是您所需要的。
我尝试使用Jenkinsfile中的System.setProperty（）指向已签入项目的文件，该文件是使用Jenkins文件凭据创建的，并通过使用writeFile步骤直接写入包含配置文件的字符串到构建工作区。在每种情况下，Jenkins似乎根本找不到krb5.conf文件，并且出现相同的“无法找到默认领域”错误。
出于各种原因将文件放在/ etc中是有问题的。另外，当有一个明确阐明的算法可以找到Kerberos配置文件时，我真的应该把它放在那里吗？
如果您知道发生了什么事，将不胜感激。
注意事项：我已经使用此处存在问题的krb5.conf和login.conf文件成功通过了Kerberos身份验证。他们工作。 Kerberos和我的配置似乎不是问题。詹金斯在做什么或不在做什么似乎都是问题所在。
答案 0 :(得分：1)
回答我自己的问题，因为我最终找到了解决方案，并在我们的构建过程中成功地通过Jenkins Pipeline成功地使用了Kerberos身份验证。
我们的Jenkins实例在AWS云的一小部分中使用了许多执行程序。实际上，在执行程序上运行的管道的唯一部分是构建步骤：Jenkins将工作空间签出到构建节点（执行程序）并在这些节点上执行构建。
几乎所有其他内容以及Jenkins所谓的全局共享库中的所有内容（包括我最初问题中引用的Kerberos代码）实际上都在主服务器上运行： 您在Jenkinsfile的node（）步骤中将对函数的调用包装在全局共享库中，这些调用仍在master上运行。
因为显然是吧？
我试图做的是将krb5.conf文件放在应该在构建节点上的所有位置。但是，由于我的Kerberos代码不是构建的一部分（或其他几个步骤之一，如在jenkins的节点上运行的sh（）），因此它不是在节点上发生的：它是在Jenkins主节点上发生的。即使调用被包装在一个节点步骤中。我不苦很好。
将krb5.conf文件放置在主服务器上的正确位置可以解决此问题，但会带来其他问题。最终，我将Kerberos逻辑以及相应的配置文件放入了jar中的一个小型Java命令行实用程序中。这是通过curl下载并执行的，所有操作都在我们管道的sh（）步骤中进行。这不是最优雅的解决方案，但是即使在与Cloudbees支持人员讨论了问题之后，这也是他们针对我们正在尝试做的事情推荐的解决方案。