several issues

[Peter]

Hi there,

just for .*, this is my 1st post here in this group. And yes, i know i should open some tickets @cloudbees, but i want to check first if anyone here got's stuck on the same issues. For the records: jenkins server 2.204 runs on latest CentOS7.

Issue1: Anyone noticed that when logged in as admin user, you'll get the info that a new version of jenkins is out, but the link to the changelog gives you infos about the previous version ? Takes 2-3 days until the correct link comes up... updates to the changelog did happen earlier some weeks ago.

Issue2: Using the "Check job prerequisites" plugin. When selecting "windows batch command" in any job, it is saved ok, reading the job's xml file. When loading job configuration again, it is displayed as "shell script" and saved as such (not as "windows batch command"). Looks like a bug.

Issue3: Never succeeded in installing a jenkins Agent as a Windows service. The qa environment here needs a CIFS mount to be accessible. Using windows agents through SSH works in general, but... no access to a CIFS share, too. Any ideas? Somewhat related to https://cygwin.com/ml/cygwin/2004-09/msg00087.html

Issue4: Any hints to detect which agent is meant when the message "SSH Host Key Verifiers are not configured for all SSH agents on this Jenkins instance. This could leave these agents open to man-in-the-middle attacks. Update your agent configuration to resolve this." is shown? We have 50+ agents running, but neither logs, nor logging in to any of our machines gives me any hint who the culprit is? Would it be possible to make this message say WHICH agent is the culprit? Even server logs do not tell which agent it is.

Issue5: Remoting disconnects early when it is started as Client/Agent on Windows(7/10) when IPv6 privacy extensions have been enabled. How can i configure Remoting to use the 'prefered' IPv6 address as source address when it connects to the jenkins server, instead of the actual/temporary privacy IPv6 privacy address? Somewhat related to https://issues.jenkins-ci.org/browse/JENKINS-33287, which is reproducible.

 Cheers, Peter

[Mark Waite]

On Mon, Nov 25, 2019 at 9:56 PM Peter <pk68...@gmail.com> wrote:

Hi there,

just for .*, this is my 1st post here in this group. And yes, i know i should open some tickets @cloudbees, but i want to check first if anyone here got's stuck on the same issues. For the records: jenkins server 2.204 runs on latest CentOS7.

I'm not aware of any organization (including CloudBees) that offers support for weekly releases.  If you want to purchase support, you should probably use the long term support release (current 2.190.3) rather than a weekly release.

If you're using git as your source control system, then you probably also want to install a newer version of git than is naturally installed with CentOS 7.  Git version 1.8 as included with CentOS 7 was initially released 7 years ago.  It lacks the many improvements that have been made to git as it has evolved to the current git 2.24 release.

 

Issue1: Anyone noticed that when logged in as admin user, you'll get the info that a new version of jenkins is out, but the link to the changelog gives you infos about the previous version ? Takes 2-3 days until the correct link comes up... updates to the changelog did happen earlier some weeks ago.

Yes, the person that was creating the changelog previously was more punctual than I've been the last few weeks.  Since the changelog is created on personal time and with personal effort, the transition from the previous maintainer of the changelog to me has caused me to respond more slowly than the previous maintainer did.  I may become more willing to spend my late Sunday evening preparing the changelog in the future, but that is assuming I'm willing to surrender my Sunday evening every week to create the changelog.

Would you like to help with generating the changelog?  I'm happy to host a session with you, show you the techniques, and let you assist, especially on those times when my personal time is not as available.

We are moving towards more and more automation of the Jenkins changelog process.  We've already automated many of the plugin changelogs, but the Jenkins changelog is larger and more complicated than any plugin changelog.  We hope to continue making progress on that automation in coming weeks and months.

 

Issue2: Using the "Check job prerequisites" plugin. When selecting "windows batch command" in any job, it is saved ok, reading the job's xml file. When loading job configuration again, it is displayed as "shell script" and saved as such (not as "windows batch command"). Looks like a bug.

Could be a bug.  Follow the directions at "How to report an issue" and once you've confirmed that it really is an issue, report it.

 

Issue3: Never succeeded in installing a jenkins Agent as a Windows service. The qa environment here needs a CIFS mount to be accessible. Using windows agents through SSH works in general, but... no access to a CIFS share, too. Any ideas? Somewhat related to https://cygwin.com/ml/cygwin/2004-09/msg00087.html

Personal opinion mode on

Windows file system access is already painfully slow.  Don't make it worse by using a network file system.  Use a local file system for the agent rather than a network file system.  You'll avoid complexities with git repositories and with other forms of file access in Jenkins.

I prefer to launch Windows agents on Windows 10 and Windows Server 2019 using the Windows OpenSSH server port.  Instructions are available in the ssh slaves configuration manual .

Personal opinion mode off

 

Issue4: Any hints to detect which agent is meant when the message "SSH Host Key Verifiers are not configured for all SSH agents on this Jenkins instance. This could leave these agents open to man-in-the-middle attacks. Update your agent configuration to resolve this." is shown? We have 50+ agents running, but neither logs, nor logging in to any of our machines gives me any hint who the culprit is? Would it be possible to make this message say WHICH agent is the culprit? Even server logs do not tell which agent it is.

Good suggestion for an enhancement.  Enhancement requests are submitted to the same tracker as is used for bug reports.

As a short term work around,  If you're using static agents, then the definition of the static agents are stored in %JENKINS_HOME%\nodes.  One or more of the configuration files in that directory will include the text "sshHostKeyVerificationStrategy" with a "class=" entry on the same line which tells you the type of verification used by that agent.  The name of the class will tell you the type of verification being used.

Issue5: Remoting disconnects early when it is started as Client/Agent on Windows(7/10) when IPv6 privacy extensions have been enabled. How can i configure Remoting to use the 'prefered' IPv6 address as source address when it connects to the jenkins server, instead of the actual/temporary privacy IPv6 privacy address? Somewhat related to https://issues.jenkins-ci.org/browse/JENKINS-33287, which is reproducible.

Sorry, no idea on this one.

Mark Waite

 

 Cheers, Peter

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/57099dd3-c19d-4619-80c0-5782871f1a94%40googlegroups.com.

--

Thanks!

Mark Waite

[Simon Richter]

Hi,

On Mon, Nov 25, 2019 at 06:30:36PM -0800, Peter wrote:

> Issue3: Never succeeded in installing a jenkins Agent as a Windows service.

The way I did it:

- start agent in JNLP mode once, wait for it to download and initialize
- shut down agent
- open a cmd.exe with Administrator privileges
- go to agent directory, run "jenkins-slave.exe install"
- adjust service configuration in Microsoft Management Console

> Issue5: Remoting disconnects early when it is started as Client/Agent on
> Windows(7/10) when IPv6 privacy extensions have been enabled. How can i
> configure Remoting to use the 'prefered' IPv6 address as source address
> when it connects to the jenkins server, instead of the actual/temporary
> privacy IPv6 privacy address?

Outgoing connections should automatically select the currently preferred
address, but PE generates a new preferred address every twenty minutes and
then lets the old one expire after a while. It might help to increase the
expiry time, but long-running connections and Privacy Extensions generally
don't mix well.

Simon

[SAIFUL ALAM]

Hello sir i don't understand who you are saying please explain to me a little sir

--

[Ivan Fernandez Calvo]

Issue4: Any hints to detect which agent is meant when the message "SSH Host Key Verifiers are not configured for all SSH agents on this Jenkins instance. This could leave these agents open to man-in-the-middle attacks. Update your agent configuration to resolve this." is shown? We have 50+ agents running, but neither logs, nor logging in to any of our machines gives me any hint who the culprit is? Would it be possible to make this message say WHICH agent is the culprit? Even server logs do not tell which agent it is.

I have created https://issues.jenkins-ci.org/browse/JENKINS-60289 

[Ivan Fernandez Calvo]

Issue5: Remoting disconnects early when it is started as Client/Agent on Windows(7/10) when IPv6 privacy extensions have been enabled. How can i configure Remoting to use the 'prefered' IPv6 address as source address when it connects to the jenkins server, instead of the actual/temporary privacy IPv6 privacy address? Somewhat related to https://issues.jenkins-ci.org/browse/JENKINS-33287, which is reproducible.

you could try to pass `-Djava.net.preferIPv4Stack=true` to the remoting process to force to use IPv4 when you enabled this extension

[Peter]

Thanks a lot to all who've replied, this mailing list rocks! I'll try to summarize:

I've asked here, because the wiki page "How to report an issue" tells me "The Jenkins JIRA is not a support site. If you need assistance or have general questions, visit us in chat, or email one of the mailing lists." on the very first lines. See https://wiki.jenkins.io/display/JENKINS/How+to+report+an+issue

Still using subversion, so the hint about a too old git version on stock CentOS7 doesn't matter here.

My apologies, Mark Waite. I didn't know that the maintainer of the changelog url changed, and i guess all of us jenkins users respect your effort to make it happen as good and fast as possible. Since you've asked for help to get an automatic changelog page, i would like to give it a try when you give me more infos about how it should go, and which kind of environment is available. Shell and/or Tcl scripting would be no problem, but don't ask me about groovy.

About personal opinions about M$ file systems: agreed. scp or sshfs would help, but isn't much better. The key point here is, regression test machines in the local environment report results and logfiles to a network file system. Not a real performance issue. Other regression tests do some ftp transfers, and scripts need to check what and how much does get there (via CIFS share). So, instead of starting a JNLP session on each Windows agent manually (with access to a network share), it would be nice to see a solution which runs "jenkins as a service" (currently without error-less solution that has access to a network share). Thanks Simon for your hints, tried again, but still without success. Gives something like 'no access to Windows Event log' and exited. Thanks Simon Richter for your tips. Need to investigate and will report when having success.

About the "Check job prerequisites" jenkins plugin (aka "Slave Prerequisites plugin"... shouldn't this be named "Agent Prerequisites plugin" soon?): I have checked this with a fresh jenkins LTS and latest weekly distribution, and issue2 is reproducible: Select "windows batch command" at "Check job prerequisites" in any job, it is saved ok, reading the job's xml file. When loading job configuration again, it is displayed as "shell script" and saved as such (not as "windows batch command"). Ok, i guess i have to create an JIRA account&issue...

Thanks a lot, Ivan Fernandez Calvo, for opening JENKINS-60289. It's not a real showstopper, but it is time consuming to manually login to each (of many) ssh clients witthout detecting any issues, just (not) to get rid of a jenkins warning (which possibly sits in some kind of not-updated cache?). BTW, a 'grep sshHostKeyVerificationStrategy nodes/*/config.xml' in CWD=~jenkins reports the expected class="hudson.plugins.sshslaves.verifiers.KnownHostsFileKeyVerificationStrategy" for all nodes.

About Remoting disconnects: https://issues.jenkins-ci.org/browse/JENKINS-33287 is still reproducible on Windows with disabled IPv4 stack (which is a requirement for local regresssion tests).

 Thaaanks & Cheers, Peter