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

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
<https://wiki.jenkins.io/display/JENKINS/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 <https://xgtj.dionglobal.de/jenkins/computer/>
> 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-users+unsubscr...@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
> <https://groups.google.com/d/msgid/jenkinsci-users/57099dd3-c19d-4619-80c0-5782871f1a94%40googlegroups.com?utm_medium=email&utm_source=footer>
> .

Mark Waite

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-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

Reply via email to