[go-cd] Preventing manual progressing of failed stages

2022-10-31 Thread hans.dush...@gmail.com
Hi, 

Is there a feature/plugin in GoCD that disallows force-manual-progress of a 
failed stage, for certain groups of users? (I can see that there is this 
allowOnlyOnSuccess for approval at stage level, but is there a way to 
configure this so that say an Admin can in an exceptional situation 
manually override this)

Thanks,
Hans

-- 
You received this message because you are subscribed to the Google Groups 
"go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to go-cd+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/go-cd/ee6fe57d-7b72-4502-bc26-76dc7430c3c6n%40googlegroups.com.


Re: [go-cd] Issues with GoCD db.properties file and LDAP after upgrade to 20.4.

2022-10-31 Thread Funkycybermonk
This might be simplified massively. It seems that it will function properly 
on the local machine as localhost and from a remote machine as the machine 
name. We alias them as a cname since our servernames are pretty complex so 
perhaps the issue is that its not properly authenticating/redirecting 
because it needs to have alternate site name bindings entered somewhere?

I believe I've discovered that the missing config file prompts are not 
always valid because I've had that message right before logging indicating 
it loaded the file it thinks it couldn't find. I may try running this on up 
to 22.2 to see if this is completely just issues with aliasing the site. If 
that is a known issue/resolution that might solve my problem to know the 
workaround.

Thanks!

On Monday, October 31, 2022 at 1:20:59 PM UTC-5 Funkycybermonk wrote:

> As an add-on to this for diagnostic purposes, I reset back to 20.1 and its 
> literally on 20.2 that the issue occurs so nothing beyond that matters 
> much. Its the version that SSL changed so I don't think that matters but 
> just wanted to add that. I'm trying to get some more debug logging to get a 
> better idea whats going on under the hood when the authentication is 
> finished. Interestingly enough, if I go to /go/api/support I'm prompted for 
> authentication and the LDAP that doesn't seem to do anything on the web 
> server dashboard login, works perfectly there. I know this isn't the case, 
> but this feels sort-of like I'd expect if an authentication token wasn't 
> getting passed or a cookie was being lost on a .net site I was working with.
>
> And to go back to the method of starting, this was a pure 20.1 install 
> with nothing changed except for some templates copied over from another 
> working server. Every agent registration, pipeline group, environment, etc. 
> was all set up by hand so there shouldn't be any garbage in play. I can 
> remove the templates from the config and see if that does anything but I'd 
> think that would result in an error message or loading a blank config 
> rather than always redirecting back to login on successful login. This is 
> with no database change (not that its expected with 20.2 but just to 
> clarify state) so I've quite literally just double clicked on the installer 
> and let it run and then tried logging back in. This server I don't mind 
> doing a bit of diagnostic changes but this is prepping for some pretty 
> complex servers so I'm trying to sort out all the complexities on the side 
> before I start with a production system that is going to be pathing the 
> same (20.1+). 
>
> I did try adding a config line 
> for 
> wrapper.java.additional.100=-Dplugin.cd.go.authentication.ldap.log.level=debug
>  
> but that only expanded out the steps the ldap plugin was taking to get a 
> successful authentication, it doesn't say what happens afterwards and 
> nothing is being logged to the go-server.log or go-server-wrapper.log when 
> the authentication completes. I also tried going the extra step of 
> recording the session in chrome to see if I could see the redirect 
> happening at the url level but as far as the recording was concerned it 
> just reloads the page.
>
> If there are any tips on logging in the logback-include.xml I'd love to 
> hear it. I've tried just the default xml from the documentation for 
> logging. I'll update as I have more information, I'm just basically trying 
> to adjust all the settings I can find to debug to get as much information 
> as possible. I'm not opposed to doing heavy lifting in the logs, I just 
> haven't yet found the proper thing to give me all the details I'd like to 
> see.
>
> I really appreciate the responses and assistance!!
>
>
> On Friday, October 28, 2022 at 9:02:30 PM UTC-5 Funkycybermonk wrote:
>
>> What I had done was go to 20.4, then upgrade the DB as a preparation step 
>> for continuing to 22.2. I have this time rolled back to 20.1, confirmed it 
>> was active and then went directly to 20.5. As expected, the DB was not 
>> compatible so I again installed and configured PostgreSQL per docs and 
>> upgraded the database from H2->PostgreSQL. 
>>
>>  
>>
>> I did run into the issue again with the git url being rejected so I’ve 
>> done the same fix there but I’m hoping that hasn’t been removed as an 
>> allowed feature since we do too many large repo pulls across multiple 
>> machines to do over the internet every time.
>>
>>  
>>
>> I’m at 20.5 now and back to roughly the same place. LDAP is blowing up 
>> with the messages after which authentication is successful but doesn’t 
>> redirect into the dashboard.:
>>
>> I went through the previous process of removing the security section from 
>> the cruise config and adding the authorization provider back in as LDAP 
>> without checking the box for strict access. It redirects back to login and 
>> the loop restarts.
>>
>>  
>>
>> I’m still not getting anything that I can see logged into the database, 
>> for example 

Re: [go-cd] Issues with GoCD db.properties file and LDAP after upgrade to 20.4.

2022-10-31 Thread Funkycybermonk
As an add-on to this for diagnostic purposes, I reset back to 20.1 and its 
literally on 20.2 that the issue occurs so nothing beyond that matters 
much. Its the version that SSL changed so I don't think that matters but 
just wanted to add that. I'm trying to get some more debug logging to get a 
better idea whats going on under the hood when the authentication is 
finished. Interestingly enough, if I go to /go/api/support I'm prompted for 
authentication and the LDAP that doesn't seem to do anything on the web 
server dashboard login, works perfectly there. I know this isn't the case, 
but this feels sort-of like I'd expect if an authentication token wasn't 
getting passed or a cookie was being lost on a .net site I was working with.

And to go back to the method of starting, this was a pure 20.1 install with 
nothing changed except for some templates copied over from another working 
server. Every agent registration, pipeline group, environment, etc. was all 
set up by hand so there shouldn't be any garbage in play. I can remove the 
templates from the config and see if that does anything but I'd think that 
would result in an error message or loading a blank config rather than 
always redirecting back to login on successful login. This is with no 
database change (not that its expected with 20.2 but just to clarify state) 
so I've quite literally just double clicked on the installer and let it run 
and then tried logging back in. This server I don't mind doing a bit of 
diagnostic changes but this is prepping for some pretty complex servers so 
I'm trying to sort out all the complexities on the side before I start with 
a production system that is going to be pathing the same (20.1+). 

I did try adding a config line 
for 
wrapper.java.additional.100=-Dplugin.cd.go.authentication.ldap.log.level=debug 
but that only expanded out the steps the ldap plugin was taking to get a 
successful authentication, it doesn't say what happens afterwards and 
nothing is being logged to the go-server.log or go-server-wrapper.log when 
the authentication completes. I also tried going the extra step of 
recording the session in chrome to see if I could see the redirect 
happening at the url level but as far as the recording was concerned it 
just reloads the page.

If there are any tips on logging in the logback-include.xml I'd love to 
hear it. I've tried just the default xml from the documentation for 
logging. I'll update as I have more information, I'm just basically trying 
to adjust all the settings I can find to debug to get as much information 
as possible. I'm not opposed to doing heavy lifting in the logs, I just 
haven't yet found the proper thing to give me all the details I'd like to 
see.

I really appreciate the responses and assistance!!


On Friday, October 28, 2022 at 9:02:30 PM UTC-5 Funkycybermonk wrote:

> What I had done was go to 20.4, then upgrade the DB as a preparation step 
> for continuing to 22.2. I have this time rolled back to 20.1, confirmed it 
> was active and then went directly to 20.5. As expected, the DB was not 
> compatible so I again installed and configured PostgreSQL per docs and 
> upgraded the database from H2->PostgreSQL. 
>
>  
>
> I did run into the issue again with the git url being rejected so I’ve 
> done the same fix there but I’m hoping that hasn’t been removed as an 
> allowed feature since we do too many large repo pulls across multiple 
> machines to do over the internet every time.
>
>  
>
> I’m at 20.5 now and back to roughly the same place. LDAP is blowing up 
> with the messages after which authentication is successful but doesn’t 
> redirect into the dashboard.:
>
> I went through the previous process of removing the security section from 
> the cruise config and adding the authorization provider back in as LDAP 
> without checking the box for strict access. It redirects back to login and 
> the loop restarts.
>
>  
>
> I’m still not getting anything that I can see logged into the database, 
> for example running a backup doesn’t add a record to the serverbackups 
> table in the database.
>
> Is there any chance there is a required intermediate step of upgrading to 
> 20.3 or something before going higher?
>
>  
>
> I can also try doing an H2 upgrade instead of going to PostgreSQL but that 
> won’t solve the DB issue, that would just be getting a DB working at all.
>
>  
>
>  I'm happy to send my support page (sanitized) if that helps.
>
>
> Thanks! 
>
>  
>
> *From:* go...@googlegroups.com  *On Behalf Of *Chad 
> Wilson
> *Sent:* Thursday, October 27, 2022 3:20 AM
> *To:* go...@googlegroups.com
> *Subject:* Re: [go-cd] Issues with GoCD db.properties file and LDAP after 
> upgrade to 20.4.
>
>  
>
> Sorry, one major thing to clarify - when you say 20.4 did you actually 
> mean 20.5? The db migration and OSS support for postgres via 
> config/db.properties is only in 20.5 so if you were getting errors on 
> startup on 20.4, that would be unrelated to any