Jenkins exécuté par anonymous: L'ID utilisateur doit toujours être non nul grâce à DefaultUserCanonicalIdResolver

Question

J'ai accidentellement modifié les paramètres de sécurité sans le savoir, nous avons donc dû effacer la liste d'accès de tous les membres et redémarrer. Il y a maintenant un utilisateur anonyme (ce qui est nouveau - nous avions un utilisateur "admin"). Il semble que l'utilisateur anonyme Jenkins est avorte emplois et cette erreur est affiché:

FATAL: The user id should be always non-null thanks to DefaultUserCanonicalIdResolver 
java.lang.IllegalStateException: The user id should be always non-null thanks to DefaultUserCanonicalIdResolver 
    at hudson.model.User.get(User.java:401) 
    at hudson.model.User.get(User.java:362) 
    at hudson.model.User.get(User.java:481) 
    at jenkins.model.CauseOfInterruption$UserInterruption.getUser(CauseOfInterruption.java:86) 
    at jenkins.model.CauseOfInterruption$UserInterruption.print(CauseOfInterruption.java:95) 
    at hudson.model.Executor.recordCauseOfInterruption(Executor.java:276) 
    at hudson.model.Run.execute(Run.java:1755) 
    at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) 
    at hudson.model.ResourceController.execute(ResourceController.java:98) 
    at hudson.model.Executor.run(Executor.java:410) 
ERROR: Post-build steps failed 
java.lang.NullPointerException 
    at hudson.model.JobProperty.getDescriptor(JobProperty.java:105) 
    at hudson.model.JobProperty.getDescriptor(JobProperty.java:79) 
    at hudson.model.Descriptor.toMap(Descriptor.java:973) 
    at hudson.model.Job.getProperties(Job.java:558) 
    at hudson.model.Build$BuildExecution.cleanUp(Build.java:196) 
    at hudson.model.Run.execute(Run.java:1785) 
    at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) 
    at hudson.model.ResourceController.execute(ResourceController.java:98) 
    at hudson.model.Executor.run(Executor.java:410) 

Answer 1

gérez-vous votre serveur Jenkins avec un outil de gestion de configuration comme des marionnettes? Nous avons constaté que l'un de nos modules Puppet Jenkins aimait exécuter les commandes d'administration de Jenkins en utilisant l'accès distant CLI plus l'utilisateur admin. Lorsque notre liste d'utilisateurs a changé et que l'administrateur a disparu, les commandes continueraient à fonctionner grâce à l'authentification anonyme, mais Jenkins a paniqué quand on lui a demandé de s'authentifier en utilisant un utilisateur inexistant. Pour rendre les choses plus amusantes, Puppet fonctionnait comme un service, programmé toutes les 30 minutes, donc nous avons eu cette erreur encore et encore dans les logs.

Il y a quelques options:

• Si vous devez avoir, ajouter à nouveau l'utilisateur « admin ».
• (Solution à faible loyer) Ne lancez pas votre outil de gestion de configuration en tant que service sur la boîte de Jenkins, mais lancez-le avec des commandes uniques. Cela ne supprimera pas le problème sous-jacent causant cette trace de pile (en essayant de s'authentifier en tant qu'administrateur lorsqu'il n'y a pas d'utilisateur), mais cela pourrait aider à rendre les journaux plus silencieux lors du diagnostic de la panne.
• Modifiez votre script de gestion de la configuration pour configurer Jenkins d'une autre manière, de sorte qu'il évite de chatouiller l'authentification de l'utilisateur.