from:"Ben Castellucci"

Re: Terminology Updates

2020-06-13 Thread Ben Castellucci

I don't really ever weigh in on things but this time I'd like to.

I think its safe to say no one wants anything with a space or special
chars, due to obvious technical issues.

In that vein, 'Jenkins Server' could have such technical implications plus
it is very broad.

So we're left with one word alternatives, so here's a short list of me just
brain storming a little:

- controller (this is my favorite but I think someone objected a while
back)
- commander
- coordinator
- leader (a bit of a stretch)
- primary (sounds ok to me - 'primary node', 'agent node', etc.)
- first
- main

Most of these (with the exception maybe of 'commander' and 'leader')
already appear in the vernacular & are well known.

My vote is 'controller' or 'primary'.

Thanks,
Ben

On Sat, Jun 13, 2020, 5:47 PM Slide  wrote:

> Yes, the whole point of this thread is for discussion of all aspects,
> including all the technical issues that we will have.
>
> On Sat, Jun 13, 2020 at 2:18 PM Mark Waite 
> wrote:
>
>>
>>
>> On Sat, Jun 13, 2020 at 3:04 PM James Nord  wrote:
>>
>>>
>>> but you can not talk about the Jenkins server and know what the other is
>>> talking about without saying, you mean Linux or the java process thing it's
>>> a recepie for disaster or turning 2 words into 6 every time you want to use
>>> it.
>>>
>>> today sure we say login to jenkins using my example. but asking say
>>> what's the memory of the Jenkins server..
>>>
>>> when you want to be OS agnostic (not all Jenkins run in Linux) refering
>>> to the server is highly advantageous.
>>>
>>>
>> I see.  So you would reserve the word "server" for a higher level than
>> the Jenkins java process.  That is reasonable, though it means we need a
>> different word or phrase than "server"
>>
>>
>>> I just see this as something that would bite us in the future,
>>> irrespective of any technical issues (raised by Daniel)
>>>
>>>
>> I like Daniel's idea of more precisely describing the scope of the
>> changes related to this renaming and how they would be implemented.  I'll
>> reply there with some ideas for discussion.
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtEDr7b6sMVVFBBxd4J8FfFLCFGzhVpFDDHpXQxuvOxGxA%40mail.gmail.com
>> 
>> .
>>
>
>
> --
> Website: http://earl-of-code.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVfc0kdVi_RDiKp4RATipbwPBAMYo%3Df20PoNhaMSw%2B5Y5w%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAD34T66sc09UKknN%2B881LR1ktyU5q7F_O%3DPOh9zzsG6Z-fho%3Dg%40mail.gmail.com.

Re: Proposal: Windows support policy for Jenkins

2020-04-10 Thread Ben Castellucci

Are you mis-matched in your pairing? Windows Server 2012 is in the Windows
8 family. Windows Server 2008 is the 'mate' to Windows 7, isn't it?

On Fri, Apr 10, 2020, 8:48 AM Tim Jacomb  wrote:

> Sounds reasonable to me +1,
> I speak as someone who barely ever touches Windows and never for Jenkins
> though
>
> Thanks
> Tim
>
> On Friday, 10 April 2020 13:26:51 UTC+1, Oleg Nenashev wrote:
>>
>> Dear all,
>>
>> As you probably know, Jenkins core and some plugins contain native code,
>> and hence they rely on operating systems and platforms. In principle
>> Jenkins can run everywhere where you can run Java 8 or Java 11, but in
>> practice there are some limitations. Notably we use Java Native Access  and
>> Java Native Runtime libraries which provide wide support for platforms, but
>> there are other components. In the case of Windows platforms we use Windows
>> Service Wrapper (WinSW)  and Windows
>> Process Management Library (WinP) ,
>> which depend on Windows versions and, in the case of windows services, on
>> .NET Framework.
>>
>> In the Jenkins Platform SIG  we have
>> an open topic about Windows support policy in Jenkins. Currently we have no
>> documented support policy for Windows, and it becomes an obstacle for
>> maintainers of Windows-focused components and plugins in the
>> Jenkins project. As a maintainer of WinSW and WinP, I have to be very
>> conservative about Windows support. But it comes at a cost to users, not
>> just maintenance overhead. At the end of the day it also blocks us from
>> adopting new Windows features and making Jenkins more stable/maintenable on
>> modern Windows platforms.
>>
>> I know for sure that there are Jenkins users running on Windows XP, but
>> IMHO it becomes more and more legacy use-case. Last popular industry
>> version had EoL in 2019 (WinXP Exmbedded POSReady
>> ),
>> and IMO it is time to drop WinXP support in new Jenkins releases. Same goes
>> to 32bit systems and non-mainstream architectures like Itanium, we could
>> at least reduce the support level there.
>>
>> I suggest the following policy:
>>
>>- All installers and service wrappers require Windows 7 / Windows
>>Server 2012 or above (and .NET framework 4.0+). They support 64bit
>>platforms only. Support for other platforms are provided via manual
>>jenkins.war deployment
>>- Jenkins master runtime requires Windows 7 / Windows Server 2012 or
>>above. It may work on older versions, but we do not guarantee 
>> compatibility
>>- Jenkins agent runtime requires Windows 7 / Windows Server 2012 or
>>above. It may work on older versions, but we do not guarantee 
>> compatibility
>>- For all Windows service installations .NET Framework 4.0 or above
>>is required. It is a default version in Windows versions specified above
>>- Jenkins master and agent Docker images are not required to provide
>>images for the supported platforms. They can move ahead as maintainers
>>prefer
>>- Plugins can define their own support policy, but they are strongly
>>advised to align their Windows support policy with the Jenkins Core
>>versions.
>>   - We have no way to communicate potential Windows support issues
>>   via update center at the moment, so following the Jenkins core 
>> requirements
>>   is what we can recommend as the best option
>>- Custom Jenkins packaging may have different requirements
>>(Jenkinsfile Runner, WARs built by Custom WAR Packager)
>>
>> Would appreciate feedback from maintainers and Windows users! Any
>> comments and change suggestions are welcome.
>>
>> If other Plaftorm SIG folks agree with me, I would suggest to add this
>> area to the Jenkins Roadmap . I
>> also created a JENKINS-61865
>>  EPIC to track
>> changes there. I will create tasks in the EPIC once there is a consensus in
>> this thread.
>>
>> Best regards,
>> Oleg Nenashev
>> Platform SIG
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/c755618e-b046-44b9-b155-38fdaba6d214%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to

Re: Launching Jenkins war from command line

2015-06-18 Thread Ben Castellucci

I'll start by stating that i don't know how Jenkins does it exactly -
you'll have to poke around the source to figure out its classloading tricks.

That said, i do know how you do it without special classloading tricks.

It is 2 parts - first part is to extract all jars involved in the servlet
container to one directory, then add your main class with some lines of
code to start up an instance of the container and reference that main class
in your manifest.

Then jar up that entire directory and you should be able to do something
like:

Java -jar my.jar

Once that is working, on to the second part...

Go back to your uber directory and start adding your web stuff (WEB-INF,
JSPs, etc.) So it starts looking like a web app as well. This stuff lives
side by side - the entire thing looks like a jar file and a web app at the
same time.

Then go back to your main class and here is the tricky part - you need to
get the absolute path to the currently executing jar file and deploy it to
your container instance (look into protection domain).

Also you will need to choose a file system directory somewhere to have the
container extract the jar (war) file it is deploying since undoubtly you
have jars in your WEB-INF/lib and without special classloading tricks those
will have to come out of the jar (war) and onto the file system before they
can be loaded with the running web app.

Then you jar up that uber directory and give it a .war extension and you
should be able to do something like:

Java -jar my.war

And it should fire up the container then deploy itself and, as part of the
deploy process, it will extract web-inf/libs to whatever file system
directory you told it.

You should also be able to just drop my.war into any servlet container and
run it like a regular web app - all that stuff from the container you
bundled will be ignored.

Ok, that all said, i think Jenkins has a special classloader that can load
jars within jars and can therefore skip the step where all the container
jars get extracted to the uber directory. Instead it can just include the
jars directly.

Anyway, there are several examples out there on how to embed jetty and also
how to make an executable war with jetty.

The explanation above should get you going your search.

Thanks,
Ben
On Jun 18, 2015 4:14 AM, Ari Maniatis a...@ish.com.au wrote:

Jenkins (and Hudson before it) has implemented a neat trick to launching
the app without a container (tomcat, jetty, etc) being launched first.

java -jar jenkins.war

I'm trying to do the same on another project, but can't figure out how
this trick works. I understand some parts. Add a line to the MANIFEST
https://github.com/jenkinsci/jenkins/blob/master/war/pom.xml#L188...

'Main-Class': 'Main'

Where Main.class is the main class that launches the application and it is
found in the root of the war, outside the WEB-INF folder. But I've done the
same and I can't get my project to behave in the same way. Is there more to
this launch process?

Is Winstone involves in some way? I see it is a lightweight container, but
then the full Jetty deployment is also found inside Jenkins, so I'm not
understanding the intersection between the two and whether it is about this
way to launch the war.

I know this isn't about development of Jenkins exactly, but I'm hoping
someone might be able to share some pointers.

Thanks
Ari

--
You received this message because you are subscribed to the Google Groups
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an
email to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/bb024b0c-f8ed-41ec-bb3a-102cc632e636%40googlegroups.com
https://groups.google.com/d/msgid/jenkinsci-dev/bb024b0c-f8ed-41ec-bb3a-102cc632e636%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/CAD34T67XYxYXQYM9zrHSeRkPpeEhk4rXgQ_ezNT8BijjX9kPYA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: form-based auth script

2014-06-12 Thread Ben Castellucci

A good test to see if jenkins properly recognizes the container role is if
it does not offer a delete option next to the role in the matrix security
config.

Also, looks like you're trying form based and trying to get curl to store
the session cookie. You might try basic auth instead.

Out of curiosity can you log in through the gui with this setup? If that
works then there's nothing wrong with the auth setup and the problem is
with curl (for whatever reason).
On Jun 12, 2014 11:10 AM, Scott Cowan scott.cowan@gmail.com wrote:

 Thank you Robert and Ben for your tips.

 This is the closest I've been able to come to reproducing the form-based
 authentication captured with wireshark.

 curl -v -c cookies.txt http://localhost:8080/jenkins/
200 OK
 curl -v -c cookies.txt -b cookies.txt
 http://localhost:8080/jenkins/loginEntry?from=%2Fjenkins%2F
 200 OK
 curl -v -c cookies.txt -b cookies.txt -H Referer:
 http://localhost:8080/jenkins/loginEntry?from=%2Fjenkins%2F\r\n
 http://localhost:8080/jenkins/loginEntry?from=%2Fjenkins%2F%5Cr%5Cn -d
 j_username=adminj_password=admin
 http://localhost:8080/jenkins/j_security_check
 302 Found
 curl -v -c cookies.txt -b cookies.txt -X POST
 http://localhost:8080/jenkins/job/test/build?delay=0sec
 403 Forbidden  (authenticated as anonymous)

 So, I'm unsure if my POST to j_security_check didn't work, or if the roles
 in my tomcat-users.xml aren't being mapped auto-magically.  I've read
 through some tomcat docs (http://tomcat.apache.org/tomcat-7.0-doc/), but
 I'm really not sure what I'm looking for.

 Scott

 tomcat-users.xml
 ...
 role rolename=admin/
 user username=admin password=admin roles=manager-gui,admin/
 ...

 In Jenkins' Configure Global Security  Access Control  Authorization 
 Matrix-based security, the admin user has every authorization checked.


 On Wednesday, June 4, 2014 8:54:36 PM UTC-4, Ben Castellucci wrote:

 Robert is correct - when delegating you are entirely subject to
 authentication against the container. Jenkins handles no part of
 authentication in this situation. It only handles authorization via
 roles/groups which you sometimes have to tell the container to map. For
 example, you have a user scott defined in tomcat-users.xml. scott is a
 member of admin role (also defined in tomcat-users.xml). You should have no
 problems authenticating scott against the container trouble is telling the
 container that it's 'admin' role means the same 'admin' group in the
 jenkins app deployed in it. Until you do that scott cannot log into jenkins.

 It has been a while since I dealt with tomcat. In weblogic, for example,
 you would pick the combination deployment descriptors and container
 security policy then create either per-app or global role to group
 mappings. I am sure there is some sort of tomcat equivalent. Tomcat may
 just do this auto-magically. In fact, according to [1] it looks like it may
 'just work' with only what is in tomcat-users.xml.

 [1] https://wiki.jenkins-ci.org/display/JENKINS/Tomcat
  On Jun 3, 2014 3:52 AM, Sandell, Robert robert@sonymobile.com
 wrote:

 Jenkins has a servlet filter [1] that last time I checked accepts http
 basic auth. But I'm not sure how/if this works when delegating to the
 servlet container, you'd probably need to authenticate the way the
 container dictates in that case.



 [1] https://github.com/jenkinsci/jenkins/blob/master/core/src/
 main/java/hudson/security/HudsonFilter.java





 *Robert Sandell*

 Software Tools Engineer - SW Environment and Product Configuration

 Sony Mobile Communications



 *From:* jenkin...@googlegroups.com [mailto:jenkin...@googlegroups.com] *On
 Behalf Of *Scott Cowan
 *Sent:* den 2 juni 2014 21:54
 *To:* jenkin...@googlegroups.com
 *Subject:* form-based auth script



 I've followed the Java example with httpclient 4.1.2 section of
 https://wiki.jenkins-ci.org/display/JENKINS/Authenticating+scripted+
 clients and been able to successfully authenticate a client with a
 Jenkins deployed in Winstone, but I haven't been able to do so when it's
 deployed in Tomcat and access control is Delegate to servlet container.
 A GET on http://localhost:8080/jenkins; with user/pass in basic auth
 scheme returns a HTTP/1.1 500 Internal Server Error with the explanation,
 anonymous is missing the Overall/Read permission.  I've enabled
 Matrix-based security and given no permissions to Anonymous.

 I noticed the auth-method in the jenkins web.xml is FORM, whether
 deployed in Winstone or Tomcat.  Can a client authenticate with this
 configuration?  Can a client negotiate a form-based authentication some
 how?  Does anyone have an example script to do this?

 Thanks in advance,
 Scott

 --
 You received this message because you are subscribed to the Google
 Groups Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to jenkinsci-de...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout

Re: form-based auth script

2014-06-12 Thread Ben Castellucci

If login through gui works OK then try token based [1] and see if that
works.

Other than that I am stumped.

[1]
https://wiki.jenkins-ci.org/display/JENKINS/Authenticating+scripted+clients
On Jun 12, 2014 12:53 PM, Ben Castellucci ben...@gmail.com wrote:

 A good test to see if jenkins properly recognizes the container role is if
 it does not offer a delete option next to the role in the matrix security
 config.

 Also, looks like you're trying form based and trying to get curl to store
 the session cookie. You might try basic auth instead.

 Out of curiosity can you log in through the gui with this setup? If that
 works then there's nothing wrong with the auth setup and the problem is
 with curl (for whatever reason).
 On Jun 12, 2014 11:10 AM, Scott Cowan scott.cowan@gmail.com wrote:

 Thank you Robert and Ben for your tips.

 This is the closest I've been able to come to reproducing the form-based
 authentication captured with wireshark.

 curl -v -c cookies.txt http://localhost:8080/jenkins/
200 OK
 curl -v -c cookies.txt -b cookies.txt
 http://localhost:8080/jenkins/loginEntry?from=%2Fjenkins%2F
 200 OK
 curl -v -c cookies.txt -b cookies.txt -H Referer:
 http://localhost:8080/jenkins/loginEntry?from=%2Fjenkins%2F\r\n
 http://localhost:8080/jenkins/loginEntry?from=%2Fjenkins%2F%5Cr%5Cn
 -d j_username=adminj_password=admin
 http://localhost:8080/jenkins/j_security_check
 302 Found
 curl -v -c cookies.txt -b cookies.txt -X POST
 http://localhost:8080/jenkins/job/test/build?delay=0sec
 403 Forbidden  (authenticated as anonymous)

 So, I'm unsure if my POST to j_security_check didn't work, or if the
 roles in my tomcat-users.xml aren't being mapped auto-magically.  I've read
 through some tomcat docs (http://tomcat.apache.org/tomcat-7.0-doc/), but
 I'm really not sure what I'm looking for.

 Scott

 tomcat-users.xml
 ...
 role rolename=admin/
 user username=admin password=admin roles=manager-gui,admin/
 ...

 In Jenkins' Configure Global Security  Access Control  Authorization 
 Matrix-based security, the admin user has every authorization checked.


 On Wednesday, June 4, 2014 8:54:36 PM UTC-4, Ben Castellucci wrote:

 Robert is correct - when delegating you are entirely subject to
 authentication against the container. Jenkins handles no part of
 authentication in this situation. It only handles authorization via
 roles/groups which you sometimes have to tell the container to map. For
 example, you have a user scott defined in tomcat-users.xml. scott is a
 member of admin role (also defined in tomcat-users.xml). You should have no
 problems authenticating scott against the container trouble is telling the
 container that it's 'admin' role means the same 'admin' group in the
 jenkins app deployed in it. Until you do that scott cannot log into jenkins.

 It has been a while since I dealt with tomcat. In weblogic, for example,
 you would pick the combination deployment descriptors and container
 security policy then create either per-app or global role to group
 mappings. I am sure there is some sort of tomcat equivalent. Tomcat may
 just do this auto-magically. In fact, according to [1] it looks like it may
 'just work' with only what is in tomcat-users.xml.

 [1] https://wiki.jenkins-ci.org/display/JENKINS/Tomcat
  On Jun 3, 2014 3:52 AM, Sandell, Robert robert@sonymobile.com
 wrote:

 Jenkins has a servlet filter [1] that last time I checked accepts http
 basic auth. But I'm not sure how/if this works when delegating to the
 servlet container, you'd probably need to authenticate the way the
 container dictates in that case.



 [1] https://github.com/jenkinsci/jenkins/blob/master/core/src/
 main/java/hudson/security/HudsonFilter.java





 *Robert Sandell*

 Software Tools Engineer - SW Environment and Product Configuration

 Sony Mobile Communications



 *From:* jenkin...@googlegroups.com [mailto:jenkin...@googlegroups.com] *On
 Behalf Of *Scott Cowan
 *Sent:* den 2 juni 2014 21:54
 *To:* jenkin...@googlegroups.com
 *Subject:* form-based auth script



 I've followed the Java example with httpclient 4.1.2 section of
 https://wiki.jenkins-ci.org/display/JENKINS/Authenticating+scripted+
 clients and been able to successfully authenticate a client with a
 Jenkins deployed in Winstone, but I haven't been able to do so when it's
 deployed in Tomcat and access control is Delegate to servlet container.
 A GET on http://localhost:8080/jenkins; with user/pass in basic auth
 scheme returns a HTTP/1.1 500 Internal Server Error with the explanation,
 anonymous is missing the Overall/Read permission.  I've enabled
 Matrix-based security and given no permissions to Anonymous.

 I noticed the auth-method in the jenkins web.xml is FORM, whether
 deployed in Winstone or Tomcat.  Can a client authenticate with this
 configuration?  Can a client negotiate a form-based authentication some
 how?  Does anyone have an example script to do this?

 Thanks in advance,
 Scott

 --
 You received

Re: form-based auth script

2014-06-12 Thread Ben Castellucci

Ha ha ha ok, sorry, you already tried that link I sent.

(Sigh)

Maybe try again after you confirm success through the gui?

When I do this it's against jenkins deployed to weblogic. I use a
deployment plan to transform web.xml to add CLIENT-CERT to auth config and
then configure the security realm to map client certificates to users then
set jenkins to delegate. Jenkins ends up thinking it did a form based auth
when really weblogic did all the work and all the client did was provide a
certificate.

It's a niche setup and probably not appropriate for what you're doing but I
get out of having to deal with what you are at the moment.

I apologize but I really am stumped after this.

I suppose you could go back to one of your original concerns and unpack the
war, change the auth config to BASIC, repack it and try again, just to
eliminate that as a concern.
On Jun 12, 2014 1:18 PM, Ben Castellucci ben...@gmail.com wrote:

 If login through gui works OK then try token based [1] and see if that
 works.

 Other than that I am stumped.

 [1]
 https://wiki.jenkins-ci.org/display/JENKINS/Authenticating+scripted+clients
 On Jun 12, 2014 12:53 PM, Ben Castellucci ben...@gmail.com wrote:

 A good test to see if jenkins properly recognizes the container role is
 if it does not offer a delete option next to the role in the matrix
 security config.

 Also, looks like you're trying form based and trying to get curl to store
 the session cookie. You might try basic auth instead.

 Out of curiosity can you log in through the gui with this setup? If that
 works then there's nothing wrong with the auth setup and the problem is
 with curl (for whatever reason).
 On Jun 12, 2014 11:10 AM, Scott Cowan scott.cowan@gmail.com
 wrote:

 Thank you Robert and Ben for your tips.

 This is the closest I've been able to come to reproducing the form-based
 authentication captured with wireshark.

 curl -v -c cookies.txt http://localhost:8080/jenkins/
200 OK
 curl -v -c cookies.txt -b cookies.txt
 http://localhost:8080/jenkins/loginEntry?from=%2Fjenkins%2F
 200 OK
 curl -v -c cookies.txt -b cookies.txt -H Referer:
 http://localhost:8080/jenkins/loginEntry?from=%2Fjenkins%2F\r\n
 http://localhost:8080/jenkins/loginEntry?from=%2Fjenkins%2F%5Cr%5Cn
 -d j_username=adminj_password=admin
 http://localhost:8080/jenkins/j_security_check
 302 Found
 curl -v -c cookies.txt -b cookies.txt -X POST
 http://localhost:8080/jenkins/job/test/build?delay=0sec
 403 Forbidden  (authenticated as anonymous)

 So, I'm unsure if my POST to j_security_check didn't work, or if the
 roles in my tomcat-users.xml aren't being mapped auto-magically.  I've read
 through some tomcat docs (http://tomcat.apache.org/tomcat-7.0-doc/),
 but I'm really not sure what I'm looking for.

 Scott

 tomcat-users.xml
 ...
 role rolename=admin/
 user username=admin password=admin roles=manager-gui,admin/
 ...

 In Jenkins' Configure Global Security  Access Control  Authorization 
 Matrix-based security, the admin user has every authorization checked.


 On Wednesday, June 4, 2014 8:54:36 PM UTC-4, Ben Castellucci wrote:

 Robert is correct - when delegating you are entirely subject to
 authentication against the container. Jenkins handles no part of
 authentication in this situation. It only handles authorization via
 roles/groups which you sometimes have to tell the container to map. For
 example, you have a user scott defined in tomcat-users.xml. scott is a
 member of admin role (also defined in tomcat-users.xml). You should have no
 problems authenticating scott against the container trouble is telling the
 container that it's 'admin' role means the same 'admin' group in the
 jenkins app deployed in it. Until you do that scott cannot log into 
 jenkins.

 It has been a while since I dealt with tomcat. In weblogic, for
 example, you would pick the combination deployment descriptors and
 container security policy then create either per-app or global role to
 group mappings. I am sure there is some sort of tomcat equivalent. Tomcat
 may just do this auto-magically. In fact, according to [1] it looks like it
 may 'just work' with only what is in tomcat-users.xml.

 [1] https://wiki.jenkins-ci.org/display/JENKINS/Tomcat
  On Jun 3, 2014 3:52 AM, Sandell, Robert robert@sonymobile.com
 wrote:

 Jenkins has a servlet filter [1] that last time I checked accepts http
 basic auth. But I'm not sure how/if this works when delegating to the
 servlet container, you'd probably need to authenticate the way the
 container dictates in that case.



 [1] https://github.com/jenkinsci/jenkins/blob/master/core/src/
 main/java/hudson/security/HudsonFilter.java





 *Robert Sandell*

 Software Tools Engineer - SW Environment and Product Configuration

 Sony Mobile Communications



 *From:* jenkin...@googlegroups.com [mailto:jenkin...@googlegroups.com]
 *On Behalf Of *Scott Cowan
 *Sent:* den 2 juni 2014 21:54
 *To:* jenkin...@googlegroups.com
 *Subject:* form-based auth script

Re: Fast Jenkins development when manipulating static assets

2014-06-04 Thread Ben Castellucci

It's been a while since I posted to this group and I'm not in a position
where I can actually try this to verify so bear with me...

Sounds like what you need is to deploy the war exploded. Easiest way to do
that us to just unzip it and deploy the resulting directory in tomcat or
similar app server. There is probably a way to tell the embedded winstone
to deploy the directory rather than the war but just using something like
tomcat would be the quickest way.

Anyway, once done all you have to do is edit the static files directly in
the directory  refresh your browser.
 On Jun 4, 2014 7:47 PM, Kevin Burke kburke...@gmail.com wrote:

 Hello,
 I'm trying to make some changes to Javascript and CSS files in the jenkins
 project. Currently, this process looks something like:

 1. Save the new changes to the file.

 2. Run `mvn install -pl war -am -DskipTests  java -jar
 war/target/jenkins.war `

 3. Reload my browser tab and view the changes.

 This is a pretty slow feedback loop - it takes roughly 1 minute and 20
 seconds between making changes and seeing them, on my 1-year old macbook
 pro, which means you can make roughly 30 changes an hour, if you are
 completely focused while Jenkins is building and know exactly what to do
 when it's not. I believe that the static files are compiled into the
 binary; if there was some way to edit them outside of the WAR this would
 imply that the build step could be skipped.

 Tom Fennelly pointed me in the direction of intellij which can perform
 incremental builds; this is an option but would require learning intellij
 and leaving my preferred text editing tools.

 I was curious though if there is a build flag which leaves the static
 assets alone, allowing them to be edited and linked without having to
 recompile a WAR? Or maybe a different set of flags I could pass to mvn
 which would complete builds faster? Or maybe I could comment out the
 compiled asset link in lib/layout/layout.jelly, and then hard code in
 lib/layout/layout.jelly a link to a server running on my own computer, with
 a copy of the JS/CSS in question.

 In any event if there are best practices here, or a document which
 outlines best practices, I would be really grateful. I tried Googling but
 mostly found answers from people trying to implement incremental builds in
 their Jenkins instances.

 Thanks,
 Kevin

 --
 You received this message because you are subscribed to the Google Groups
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: form-based auth script

2014-06-04 Thread Ben Castellucci

Robert is correct - when delegating you are entirely subject to
authentication against the container. Jenkins handles no part of
authentication in this situation. It only handles authorization via
roles/groups which you sometimes have to tell the container to map. For
example, you have a user scott defined in tomcat-users.xml. scott is a
member of admin role (also defined in tomcat-users.xml). You should have no
problems authenticating scott against the container trouble is telling the
container that it's 'admin' role means the same 'admin' group in the
jenkins app deployed in it. Until you do that scott cannot log into jenkins.

It has been a while since I dealt with tomcat. In weblogic, for example,
you would pick the combination deployment descriptors and container
security policy then create either per-app or global role to group
mappings. I am sure there is some sort of tomcat equivalent. Tomcat may
just do this auto-magically. In fact, according to [1] it looks like it may
'just work' with only what is in tomcat-users.xml.

[1] https://wiki.jenkins-ci.org/display/JENKINS/Tomcat
On Jun 3, 2014 3:52 AM, Sandell, Robert robert.sand...@sonymobile.com
wrote:

Jenkins has a servlet filter [1] that last time I checked accepts http
basic auth. But I'm not sure how/if this works when delegating to the
servlet container, you'd probably need to authenticate the way the
container dictates in that case.

[1]
https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/security/HudsonFilter.java

*Robert Sandell*

Software Tools Engineer - SW Environment and Product Configuration

Sony Mobile Communications

*From:* jenkinsci-dev@googlegroups.com [mailto:
jenkinsci-dev@googlegroups.com] *On Behalf Of *Scott Cowan
*Sent:* den 2 juni 2014 21:54
*To:* jenkinsci-dev@googlegroups.com
*Subject:* form-based auth script

I've followed the Java example with httpclient 4.1.2 section of
https://wiki.jenkins-ci.org/display/JENKINS/Authenticating+scripted+clients
and been able to successfully authenticate a client with a Jenkins deployed
in Winstone, but I haven't been able to do so when it's deployed in Tomcat
and access control is Delegate to servlet container. A GET on
http://localhost:8080/jenkins; with user/pass in basic auth scheme
returns a HTTP/1.1 500 Internal Server Error with the explanation,
anonymous is missing the Overall/Read permission. I've enabled
Matrix-based security and given no permissions to Anonymous.

I noticed the auth-method in the jenkins web.xml is FORM, whether deployed
in Winstone or Tomcat. Can a client authenticate with this configuration?
Can a client negotiate a form-based authentication some how? Does anyone
have an example script to do this?

Thanks in advance,
Scott

Re: [RFC] Database plugin

2012-12-08 Thread Ben Castellucci

Quick throw out here - how about JPA? Pretty DB-independent and can provide
its own schema creation scripts and such.

Not sure about sync-ing over time.

Maybe Apache's implementation (OpenJPA) for a friendly license?

Would keep plugin developers away from writing SQL (it's just POJOs) and
let them choose their target DB vendor, even change it later.

http://openjpa.apache.org/

Again, just a thought.

Thanks,
Ben
On Dec 8, 2012 11:42 AM, Vojtech Juranek vjura...@redhat.com wrote:


  Any suggestion for abstraction improvements before I release the
  first version of the plugin?

 is limitation to SQL databases intentional?
 Personally I would add one abstraction layer, keeping hostname, credentials
 etc. in AbstractRemoteDatabase and moving SQL related stuff like
 DataSource in
 AbstractRemoteSqlDatabase which would inherit from AbstractRemoteDatabase

Re: slowness with jenkins 1.490

2012-12-07 Thread Ben Castellucci

There is another email bouncing around on this list with the subject,
memory consumption of builds that sounds a lot like it is describing the
same behavior.

Was a change made after 1.485 to load all builds when a user navigates to
the main page vs on startup?

Is that the problem here?

Just my thoughts...
On Dec 7, 2012 1:39 PM, Jesse Glick jgl...@cloudbees.com wrote:

 On 12/07/2012 01:51 AM, ohad shai wrote:

 after the upgrade the startup time decreased to few seconds.
 However, each load of a web page take from few long seconds to few
 minutes or timeout.


 Perhaps the cache is expiring too readily, so the work is done anew on
 each page load. If you can demonstrate how to reproduce this problem on a
 clean installation it should be fixable.

 Anyway loading a single build even without the help of the cache ought to
 be pretty quick, so it is likely that some page you are viewing is in fact
 trying to load a lot of builds at once. Again if this is reproducible it
 should be fixable.

  Can I set a flag to return it to previous state?


 Not that I know of.

Re: Audit2DB Plugin

2012-10-10 Thread Ben Castellucci

Ima hijack this real quick just to throw in a few comments unrelated to
what is actually being requested...

First this looks like a really cool plugin. Nice job! I want to use this
but first...

It may be advantageous to offer a configuration option of using a
datasource via JNDI defined at the container level. Even Jenkins' built-in
Winstone servlet container suports JDBC connection pooling with JNDI
lookup. Also, many Jenkins deployments reside in containers such as
Weblogic that offer strong credential encryption. The advantages to using a
connection pool versus building up and tearing down a connection each time
are obvious.

Also, it would be extremely flexible if the schema offered a build_stats
table that was 'verticle' instead of 'horizontal' meaning there are just
generic 'id',  'name' and 'value' colums for the stats. Each row could be a
different stat, it's id tied to a row in the build_details table. This
could allow dynamic stats, configurable either at the Jenkins level or the
job level (think checkbox list of availabe stats to audit). The available
stats could be added to over time and existing schemas would still be valid.

And... it may be more helpful if the build_stats table had actual job name,
build # and build id instead of build number as the name.

I may be interested in contributing but time is tight...

Let me know any thoughts.

Thanks!
Ben
On Oct 10, 2012 7:44 AM, Marco Scata msc...@hotmail.com wrote:

 Hi all.

 I'd like to have my new plugin on Jenkins org if possible.
 Current source is on GitHub
 https://github.com/mscata/jenkins-audit2db-plugin.git
 My GitHub ID is mscata

 Can I also use the Jenkins CI infrastructure? At the moment it's using
 CloudBees.

 I also started writing a wiki page at
 https://wiki.jenkins-ci.org/display/JENKINS/Audit+To+Database+Plugin
 Hope that's ok.

 Marco

CVS Plugin Changeset Date Parse Exception

2012-08-24 Thread Ben Castellucci

Greetings.

In the same vein as [1], [2] and [3], but slightly different. No changes
ever show up for any jobs and I am seeing the following exceptions:

  java.lang.RuntimeException: Change date could not be parsed
  ...
  Caused by: java.text.ParseException: Unparseable date: 2012/08/24
17:11:48
  ...

In the changelog.xml I see this:

  ...
  changeDate2012/08/24 17:11:48/changeDate
  ...

In the older CVS plugin source [4] I see this:

  ...
  private static final DateFormat CHANGE_DATE_FORMATTER = new
SimpleDateFormat(
-MM-dd HH:mm:ss);
  ...
  public void setChangeDateString(final String changeDate) {
synchronized (CHANGE_DATE_FORMATTER) {
Calendar calendar = Calendar.getInstance();
try {

calendar.setTime(CHANGE_DATE_FORMATTER.parse(changeDate));
} catch (ParseException ex) {
throw new RuntimeException(
Change date could not be parsed,
ex);
}
this.changeDate = calendar;
 }
  }

If I go into a particular changelog.xml and change the date format like so:

  changeDate2012-08-24 17:11:48/changeDate

Then exactly those changes on that build get parsed properly and show as
expected.

CVS Plugin version is 2.5 and has never been any other version (i.e., all
changelog.xml files have been created with that version).
Jenkins version is 1.447.2.

Any thoughts, anyone, as to why the plugin is writing the changeDate with
one format and then expecting to read it later in another?

[1]:https://issues.jenkins-ci.org/browse/JENKINS-12573
[2]:https://issues.jenkins-ci.org/browse/JENKINS-13017
[3]:https://issues.jenkins-ci.org/browse/JENKINS-12586
[4]:https://github.com/jenkinsci/cvs-plugin/pull/5/files

RE: CVS Plugin Changeset Date Parse Exception

2012-08-24 Thread Ben Castellucci

Thanks Michael.

Just a clarification: next Jenkins release or next CVS Plugin release? If
next Jenkins release then what are the chances of stuffing in into an LTS?

Thanks again!
Ben
On Aug 24, 2012 5:53 PM, Michael Clarke michael.m.cla...@gmail.com
wrote:

 This looks like a refactoring error. Date formats were previously held in
 an array in CvsChangeLogHelper but when Kohsuke split the toFile into
 CvsChangeLogSet the wrong date format seems to have been copied across from
 the ones available in the array.

 This has already been fixed in master so will be in the next release.

 Thanks,
 Michael

 -original message-
 Subject: CVS Plugin Changeset Date Parse Exception
 From: Ben Castellucci ben...@gmail.com
 Date: 24/08/2012 20:16

 Greetings.

 In the same vein as [1], [2] and [3], but slightly different. No changes
 ever show up for any jobs and I am seeing the following exceptions:

   java.lang.RuntimeException: Change date could not be parsed
   ...
   Caused by: java.text.ParseException: Unparseable date: 2012/08/24
 17:11:48
   ...

 In the changelog.xml I see this:

   ...
   changeDate2012/08/24 17:11:48/changeDate
   ...

 In the older CVS plugin source [4] I see this:

   ...
   private static final DateFormat CHANGE_DATE_FORMATTER = new
 SimpleDateFormat(
 -MM-dd HH:mm:ss);
   ...
   public void setChangeDateString(final String changeDate) {
 synchronized (CHANGE_DATE_FORMATTER) {
 Calendar calendar = Calendar.getInstance();
 try {

 calendar.setTime(CHANGE_DATE_FORMATTER.parse(changeDate));
 } catch (ParseException ex) {
 throw new RuntimeException(
 Change date could not be parsed,
 ex);
 }
 this.changeDate = calendar;
  }
   }

 If I go into a particular changelog.xml and change the date format like so:

   changeDate2012-08-24 17:11:48/changeDate

 Then exactly those changes on that build get parsed properly and show as
 expected.

 CVS Plugin version is 2.5 and has never been any other version (i.e., all
 changelog.xml files have been created with that version).
 Jenkins version is 1.447.2.

 Any thoughts, anyone, as to why the plugin is writing the changeDate with
 one format and then expecting to read it later in another?

 [1]:https://issues.jenkins-ci.org/browse/JENKINS-12573
 [2]:https://issues.jenkins-ci.org/browse/JENKINS-13017
 [3]:https://issues.jenkins-ci.org/browse/JENKINS-12586
 [4]:https://github.com/jenkinsci/cvs-plugin/pull/5/files

RE: CVS Plugin Changeset Date Parse Exception

2012-08-24 Thread Ben Castellucci

Gotcha.

:)
On Aug 24, 2012 6:16 PM, Michael Clarke michael.m.cla...@gmail.com
wrote:

 Next CVS plugin release.

 -original message-
 Subject: RE: CVS Plugin Changeset Date Parse Exception
 From: Ben Castellucci ben...@gmail.com
 Date: 24/08/2012 23:14

 Thanks Michael.

 Just a clarification: next Jenkins release or next CVS Plugin release? If
 next Jenkins release then what are the chances of stuffing in into an LTS?

 Thanks again!
 Ben
 On Aug 24, 2012 5:53 PM, Michael Clarke michael.m.cla...@gmail.com
 wrote:

  This looks like a refactoring error. Date formats were previously held in
  an array in CvsChangeLogHelper but when Kohsuke split the toFile into
  CvsChangeLogSet the wrong date format seems to have been copied across
 from
  the ones available in the array.
 
  This has already been fixed in master so will be in the next release.
 
  Thanks,
  Michael
 
  -original message-
  Subject: CVS Plugin Changeset Date Parse Exception
  From: Ben Castellucci ben...@gmail.com
  Date: 24/08/2012 20:16
 
  Greetings.
 
  In the same vein as [1], [2] and [3], but slightly different. No changes
  ever show up for any jobs and I am seeing the following exceptions:
 
java.lang.RuntimeException: Change date could not be parsed
...
Caused by: java.text.ParseException: Unparseable date: 2012/08/24
  17:11:48
...
 
  In the changelog.xml I see this:
 
...
changeDate2012/08/24 17:11:48/changeDate
...
 
  In the older CVS plugin source [4] I see this:
 
...
private static final DateFormat CHANGE_DATE_FORMATTER = new
  SimpleDateFormat(
  -MM-dd HH:mm:ss);
...
public void setChangeDateString(final String changeDate) {
  synchronized (CHANGE_DATE_FORMATTER) {
  Calendar calendar = Calendar.getInstance();
  try {
 
  calendar.setTime(CHANGE_DATE_FORMATTER.parse(changeDate));
  } catch (ParseException ex) {
  throw new RuntimeException(
  Change date could not be
 parsed,
  ex);
  }
  this.changeDate = calendar;
   }
}
 
  If I go into a particular changelog.xml and change the date format like
 so:
 
changeDate2012-08-24 17:11:48/changeDate
 
  Then exactly those changes on that build get parsed properly and show as
  expected.
 
  CVS Plugin version is 2.5 and has never been any other version (i.e., all
  changelog.xml files have been created with that version).
  Jenkins version is 1.447.2.
 
  Any thoughts, anyone, as to why the plugin is writing the changeDate
 with
  one format and then expecting to read it later in another?
 
  [1]:https://issues.jenkins-ci.org/browse/JENKINS-12573
  [2]:https://issues.jenkins-ci.org/browse/JENKINS-13017
  [3]:https://issues.jenkins-ci.org/browse/JENKINS-12586
  [4]:https://github.com/jenkinsci/cvs-plugin/pull/5/files

Re: Terminology Updates

Re: Proposal: Windows support policy for Jenkins

Re: Launching Jenkins war from command line

Re: form-based auth script

Re: form-based auth script

Re: form-based auth script

Re: Fast Jenkins development when manipulating static assets

RE: form-based auth script

Re: [RFC] Database plugin

Re: slowness with jenkins 1.490

Re: Audit2DB Plugin

CVS Plugin Changeset Date Parse Exception

RE: CVS Plugin Changeset Date Parse Exception

RE: CVS Plugin Changeset Date Parse Exception

14 matches

Site Navigation

Mail list logo

Footer information