Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Alex Earl
    @slide
    It should have a signup link for creating an account
    tburow
    @tburow
    disreguard - I had a jenkins IO account apparently the Jira account is not linked - (source of the confusion)
    Alex Earl
    @slide
    hmmm, it should be the same as your account on jenkins.io
    tburow
    @tburow
    I thought so too but im in - filled a ticket on that. ill test the centOS and Alpine images also
    Alex Earl
    @slide
    Thanks
    FYI, those will get triaged by the Jenkins security team and assigned to the correct people
    The security project is generally closed off so that those issues are not public
    tburow
    @tburow

    Following up on this discussion - my security issue was closed - opinion was its not jenkins problem its Debians problem :facepalm:

    but I did some more testing regardless -
    JDK11 - 2.267 - 13 Medium findings + 89 others (Debian Stretch based)
    Alpine - 2.267 - no findings - container is clean
    Centos (8) - 2.267 - no findings - Container is clean
    Default jenkins/jenkins - 2.266 - 9 high - 17 medium - 37 low - 70 informational - (Deb stretch 9.13)

    These results are all with AWS ECR scanning which uses Clair scan rules

    Alex Earl
    @slide
    :+1:
    We are looking at migrating to buster as the default image in the near future
    Mark Waite
    @MarkEWaite
    The slim image is already running buster and it includes fewer packages than the latest image.
    Alex Earl
    @slide
    Do we just need to decide in platform-sig meeting when to cut over to buster as the default?
    Mark Waite
    @MarkEWaite
    Yes. I would like to include the switch to buster as part of the JEP that I owe for Docker platform support. One of the principles is that we define a rule that causes us to stop supporting an operating system when the upstream provider stops supporting it. The other rule idea I had was to apply the concept of a "maintainer" to each Docker image with the same type of rules as we use for "adopt a plugin".
    Alex Earl
    @slide
    :+1:
    tburow
    @tburow
    :+1:
    tburow
    @tburow
    is there any noteable performacne differences between the default - centOS - & Alpine??
    Mark Waite
    @MarkEWaite
    None that I recognize. The most notable difference between Alpine and every other distribution is the C library. Alpine uses musl, almost all other distributions use glibc. There are interesting and distracting differences in DNS resolution between musl and glibc, among other differences.
    tburow
    @tburow
    good to know
    Deb 9.13 would explain the ssh shenanigains with the aws ec2-plugin
    Random thought sorry
    Tim Jacomb
    @timja
    @tburow did you check the slim images?
    tburow
    @tburow
    just did Slim (Deb10) 13 med - 86 others
    so slim reports out almost the same findings as jdk11
    Tim Jacomb
    @timja
    kk
    tburow
    @tburow
    I mean - I dont want to be “that guy” but at least for the moment I have to advise my teams to stick to CentOS or Alpine - tho the C lib for Alpine may or may not pose a problem
    the finding delta between default on deb9 and slim/JDK11 onDeb 10 is likely the lesser packages
    id have to dig deeper and do a side by side
    Alex Earl
    @slide
    Can you email me the reports to slide dot o dot mix at gmail dot com?
    tburow
    @tburow
    sure
    Gavin Mogan
    @halkeye
    i thought dockerhub had support for scanning the images, i know quay does
    Tim Jacomb
    @timja
    Dockerhub does on paid plans
    Gavin Mogan
    @halkeye
    are we on the open source one yet? does it do it?
    clair is super easy to setup though
    Tim Jacomb
    @timja
    jenkinsciinfra has:
    image.png
    I'm not on the 'jenkins' docker org
    so i think no we aren't
    and unsure
    Patrick Robinson
    @autarchprinceps
    I have an issue with combining the Jenkins Kubernetes Plugin with the Kubernetes Cluster Autoscaler. Jenkins always injects kubernetes.io/os: linux as node selector, but this isn't supported properly when autoscaling instances from 0.
    How can I tell the Jenkins Kubernetes Plugin to not set any nodeSelector? I tried setting yamlMergeStrategy: override() and specifying in the yaml that nodeSelector: {} should make it an empty dict, but Jenkins still injects its additions. I can of course explicitly set the nodeSelector os, but setting it to something other than linux is only even worse, including "" or null, which still lead to it being created with the selector, just with an unfullfillable operating system selector.
    Does anyone have an idea how I could specifically unset it, or force jenkins to not add stuff I don't want it to add?
    Alex Earl
    @slide
    You probably want to ask in the main jenkinsci/jenkins channel
    Alex Earl
    @slide
    Can someone take a look here and provide any feedback? jenkinsci/docker#1025
    Arcturus
    @arcturus140
    hello, my docker image is run with -u 1001:1001 flag. How can i run a docker image as root user, instead? My Jenkinsfile uses
    agent { dockerfile true }
    Alex Earl
    @slide
    You probably want to ask in the main jenkinsci/jenkins channel
    Arcturus
    @arcturus140
    @slide thanks, i'll ask there. What is this channel about, is this a dev channel?
    Alex Earl
    @slide
    yes, more about the actual jenkins docker images and such
    jjvdgeer
    @jjvdgeer

    I have a NAS with on which I run Jenkins docker image I made (it's an ARMv7 NAS and the provided images don't work on that platform) together with a few agent-docker-images, one for dotnet stuff and one for building docker images. This used to work, at least back in october. But I hadn't build for a while and now building docker images doesn't work anymore. There's been some updates to Jenkins and the NAS has its docker upgraded from 17.x to 19.x. I don't know what broke it, but one of these things seems likely. Firing up dotnet agents still works fine.

    When I go to my docker agent setup, I see an error saying:
    Bad Message 414
    reason: URI Too Long

    I found an article that said I should add "--requestHeaderSize=32768" to JENKINS_ARGS so I tried with

    ENV JENKINS_ARGS="--requestHeaderSize=32768"

    in the Dockerfile but it doesn't work. I also added "--httpPort=8999" expecting the website not to work anymore as that port isn't mapped, but it still works, so I think the variable isn't being read. Not sure though, as I don't really know how everything works.

    I also see errors in the logfile that to me do not really seem like the same problem as "URI Too Long" but they seem to occur when it's trying to fire up a new agent. Not sure what to make of this.

    Any suggestions how to fix this?

    halkeye
    @halkeye:g4v.dev
    [m]
    @jjvdgeer: I think you want #jenkinsci/jenkins for general support, this channel is more about building the docker images itself. That said, I'm super confused what uri it would be using, and why it would be too long, it has to be really really long for it
    jjvdgeer
    @jjvdgeer
    OK, thanks, I'll repost there. Was reading back and got the impression that I might have chosen the wrong channel, just as the previous person. Sorry about that. Not sure about this URI stuff either. It's an SSH agent, I don't really know how that works, but I imagined there not being many exciting URI's involved. But what do I know...
    Ewelina Wilkosz
    @ewelinawilkosz
    I’m having trouble with running Jenkins in a container - it runs setup wizard when I try to access the page after startup. Would appreciate advice on how to troubleshoot, here is my Dockerfile:
    FROM jenkins/jenkins:2.263.1
    COPY plugins_extra.txt /usr/share/jenkins/ref/plugins_extra.txt
    
    ENV JENKINS_HOME /var/jenkins_home
    
    (…)
    ENV JAVA_OPTS "-Dhudson.model.Slave.workspaceRoot=w -Djenkins.CLI.disabled=true -Djenkins.install.runSetupWizard=false -Dorg.apache.commons.jelly.tags.fmt.timeZone=Europe/Stockholm ${JAVA_PROXY:-}"
    
    RUN /usr/local/bin/install-plugins.sh < /usr/share/jenkins/ref/plugins_extra.txt