RE: [go-cd] LDAP Group Authentication/Roles/Permissions

[chantryc]

Do you know if this plugin allows any configuration for static agent 
modify/admin permissions? Its doing exactly what I was looking for and mapping 
permissions from roles, and also applying the role permissions for pipeline 
groups. I’m trying to see if I can give certain users permissions to add 
resource tags or assign environments to agents without giving them full admin 
access to the server. 

 

Thanks!

 

From: chant...@gmail.com  
Sent: Wednesday, November 8, 2023 2:00 PM
To: go-cd@googlegroups.com
Subject: RE: [go-cd] LDAP Group Authentication/Roles/Permissions

 

Thanks! I’ll take a look. We are using the bundled version. 

 

From: go-cd@googlegroups.com   
mailto:go-cd@googlegroups.com> > On Behalf Of Chad 
Wilson
Sent: Wednesday, November 8, 2023 1:09 PM
To: go-cd@googlegroups.com  
Subject: Re: [go-cd] LDAP Group Authentication/Roles/Permissions

 

There are multiple LDAP plugins, so it depends which one you are referring to. 
Sounds like you might want to look at 
https://github.com/gocd/gocd-ldap-authorization-plugin rather than the bundled 
'authentication-only' version?

 

-Chad

 

On Thu, 9 Nov 2023, 05:33 Funkycybermonk, mailto:chant...@gmail.com> > wrote:

Hello!

I'm trying to manage a pool of users that is going to change over time and 
their permissions across multiple GoCD servers. (regional server split)

I can add a group into permissions using the LDAP plugin, but it doesn't seem 
initially like the user permissions are inherited or managed by that group 
membership. Is it possible to do group based permissions from AD or does it 
have to be per-user?

I'm trying to minimize work since we'll have to manually replicate the roles 
and permissions across several servers. 

Thanks! 

-- 
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/4183dab6-4dad-4fd3-9055-01333843d0dbn%40googlegroups.com
 

 .

-- 
You received this message because you are subscribed to a topic in the Google 
Groups "go-cd" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/go-cd/YXdA8U4UNEY/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAA1RwH8fUnhEOODV7im%2BVU_xkTfkTEDkmpvsz_bhmDGcLrfWJA%40mail.gmail.com
 

 .

-- 
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/063a01da1d4d%24d23be980%2476b3bc80%24%40gmail.com.

RE: [go-cd] LDAP Group Authentication/Roles/Permissions

[chantryc]

Thanks! I’ll take a look. We are using the bundled version. 

 

From: go-cd@googlegroups.com  On Behalf Of Chad Wilson
Sent: Wednesday, November 8, 2023 1:09 PM
To: go-cd@googlegroups.com
Subject: Re: [go-cd] LDAP Group Authentication/Roles/Permissions

 

There are multiple LDAP plugins, so it depends which one you are referring to. 
Sounds like you might want to look at 
https://github.com/gocd/gocd-ldap-authorization-plugin rather than the bundled 
'authentication-only' version?

 

-Chad

 

On Thu, 9 Nov 2023, 05:33 Funkycybermonk, mailto:chant...@gmail.com> > wrote:

Hello!

I'm trying to manage a pool of users that is going to change over time and 
their permissions across multiple GoCD servers. (regional server split)

I can add a group into permissions using the LDAP plugin, but it doesn't seem 
initially like the user permissions are inherited or managed by that group 
membership. Is it possible to do group based permissions from AD or does it 
have to be per-user?

I'm trying to minimize work since we'll have to manually replicate the roles 
and permissions across several servers. 

Thanks! 

-- 
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/4183dab6-4dad-4fd3-9055-01333843d0dbn%40googlegroups.com
 

 .

-- 
You received this message because you are subscribed to a topic in the Google 
Groups "go-cd" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/go-cd/YXdA8U4UNEY/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAA1RwH8fUnhEOODV7im%2BVU_xkTfkTEDkmpvsz_bhmDGcLrfWJA%40mail.gmail.com
 

 .

-- 
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/00e101da127e%24279ed1b0%2476dc7510%24%40gmail.com.

RE: [go-cd] Agents going offline randomly on 22.3

[chantryc]

I’ll see if I can aggregate all the logs. 

 

For the resources, we assign values to particular agents so we can dynamically 
assign agents based on what a job step should be doing. For example if it needs 
to be local to a SQL server we’ll tag that with a code and something like SQL, 
SQL-A if its in a cluster, etc. and then it all auto-assigns to the first valid 
agent. I’m not sure that we can do auto-registration with detail so we’ve just 
done it by hand. 

 

I don’t think its crossover because I have 4-5 agents that I need to fix that 
are the only one on the server but I’ll check and see what they say. Would 
something interrupting the SQL instance cause this to occur? A write to the 
agents table being missed or timing out, etc.? I’ve had some that have both the 
token and guid but this one just has a guid. I’m going to make sure the SQL 
folders are being handled gently and that AV wouldn’t be the interference.

 

I was asking about the guid/token to see if that was stored somewhere I could 
retrieve or could be manually registered to make sure it reattached the agent 
to the assignments (environment and resources) instead of enabling the agent 
and doing all the assignments again. Some of these have quite a few resources 
to eyeball for comparisons. 

 

I’ll share back as soon as I find either more questions or a solution someone 
else might find useful.

 

Thanks!

 

From: go-cd@googlegroups.com  On Behalf Of Chad Wilson
Sent: Tuesday, April 4, 2023 11:05 AM
To: go-cd@googlegroups.com
Subject: Re: [go-cd] Agents going offline randomly on 22.3

 

Was the setup working at some point and then something changed?

It sounds to me like you have some problem with 

*   agents' identities getting confused with one another (shared GUIDs), or 
*   accidentally sharing working folders between two agent processes 
(double-starting an agent perhaps?) or 
*   token getting removed after it is first issued (by something...)

Do you have any automated re-provisioning of the agents or other automation 
here that could be interfering with the config/token or guid.txt files?

I can't really think of any other reason this would happen, and there's not 
really much information here to debug. If the agents aren't getting confused 
with one another, what this looks like is the agent still knows its GUID, but 
assuming it was previously working, the token it was previously issued has been 
lost off disk. To my knowledge the agent only actively deletes a token when the 
registration of the agent is denied by the server due to a 403 FORBIDDEN error 
after you reject registration, so If you have missing tokens for agents that 
were previously OK, perhaps you want to see what could be deleting the token?

You also may need to follow through an agent's full log and timeline to see how 
that could have happened, correlating to other events and search the server log 
for the agent's GUID to see what might be happening - snippets like the below 
aren't complete enough to be helpful. Or have a look through 
https://github.com/gocd/gocd/issues/5170

And no, you can't recreate GUID/token from PostgreSQL, but not sure what you 
mean here. Removing the GUID and token and restarting the agent should be 
sufficient to get it to re-register reliably - as long as the root problem is 
addressed that is causing the agents

As for the resource tags, is there a reason you're doing that manually? You may 
be able to use auto registration of agents to automate that? 
https://docs.gocd.org/current/advanced_usage/agent_auto_register.html

 

-Chad

 

On Tue, Apr 4, 2023 at 10:51 PM Funkycybermonk mailto:chant...@gmail.com> > wrote:

Hello! I'm running 22.3 and I keep having agents go offline. For example, on a 
particular server (mirror setup to other environments) I have several agents 
running side-by-side on an admin server and then an agent on various individual 
servers. At the moment for this particular example, I have 12 of 15 agents that 
are running perfectly fine. They all enabled and took their configs originally 
but now the two that are offline are just looping the below message. Generally 
I can go to each server, stop the agent, delete the contents of the config 
folder and restart and it may after 1 or more tries create a new entry. The new 
entry now is missing all the resource tags so we have to note all the tags from 
the abandoned agent registration and add it to the new one. 

 

We have a significant number of agents around in multiple environments but this 
happens to maybe 10-20% of them. All agents were provisioned in the same way, 
started and registered in the same way. 

 

Sometimes they have a token, and guid file but sometimes there is only a guid 
while the error message loops. In this particular agent case, I have two that 
just went offline from a clean install. Both showed up initially and enabled 
but are now showing offline. They are on the same server but each has a 
different name "Go 

RE: [go-cd] Issues with saving xml on secure url with reverse proxy

[chantryc]

Hello! 

 

This helped me find the correct setting for my situation, although I don’t know 
if it’s a universal fix since I have a dedicated IIS install for the reverse 
proxies. I couldn’t find a way to get the reverse proxy itself to work properly 
but running the below command tells the ARR module to preserve the host headers 
instead of rewriting them.:

 

The command was: 
%windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/proxy 
-preserveHostHeader:true /commit:apphost

 

Everything else I had tried just broke the proxy entirely.

 

Thanks for the help and this can be considered closed.

 

Thanks!

 

From: go-cd@googlegroups.com  On Behalf Of Aravind SV
Sent: Tuesday, January 17, 2023 11:10 AM
To: go-cd@googlegroups.com
Subject: Re: [go-cd] Issues with saving xml on secure url with reverse proxy

 

Hello,

It’s also possible that the reverse proxy is doing something to the Origin 
headers, but I have not touched IIS for a very long time, and never used it in 
a reverse proxy mode, so have no specific insight there - and to me doesn’t 
seem to explain the CSRF token errors. It also could be something not working 
as intended within GoCD.

I think it is related to the reverse proxy setup. I’ve seen this happen when 
setups ignore the “X-Forwarded-For” header setup shown  
 in 
the documentation.

How it ends up being related to CSRF tokens seems to be:

1.Server sends a response with a session ID in the cookie, along with a 
CSRF token to be sent back with the form response.

2.Due to the misconfiguration (could be secure site URL as you said), the 
cookie doesn’t get set / sent back with the form response.

3.Then, when the server tries to verify that the CSRF token sent back 
matches the one expected for the session, it doesn’t work, since the session 
won’t be the old session from point 1 above.

Something like that. I could be mistaken. Related issue which reminded me of 
this (no resolutions mentioned there, unfortunately, apart from “proxy 
configuration was the issue”):   
https://github.com/gocd/gocd/issues/5296

Regards,
Aravind

From:   Chad Wilson
Subject: Re: [go-cd] Issues with saving xml on secure url with reverse proxy
To: go-cd@googlegroups.com  
Date: Wed, 18 Jan 2023 00:08:23 +0800

Hiya

 

Not 100% sure if relevant, but is your Secure Site URL set correctly in Admin > 
Server Configuration?

With that limited description it sounds like perhaps your browser is trying to 
make cross-origin requests, e.g sending a request to https:// from something on 
http:// (or vice versa) which shouldn't really happen - especially if you are 
allowing both to work. On that theory, if you temporarily block http:// .. 8153 
access entirely you might be able to find more easily where that problem is by 
seeing which resources/pages/API calls fail within your browser because they 
are somehow linking to a non-HTTPS URL or something like that.

 

It's also possible that the reverse proxy is doing something to the Origin 
headers, but I have not touched IIS for a very long time, and never used it in 
a reverse proxy mode, so have no specific insight there - and to me doesn't 
seem to explain the CSRF token errors. It also could be something not working 
as intended within GoCD.

 

Other than that, please try and share 

*   more specific details/steps of what you are doing to replicate the 
problem; whether you have tried in incognito/private mode and have the same 
outcome - that type of thing
*   which specific actions/UI interactions are leading to the error (other 
than admin > config xml) - "a few issues" isn't very specific here. If the 
outcome/error is the same, we should try and establish a pattern as to which 
things are affected.
*   please share exact and full error logs/traces, rather than partial 
pieces or descriptions. I think there should be a much larger log than this 
including the request details; with which you can partially redact anything 
sensitive.
*   what changed between when it worked and when it didn't work? It's not 
clear whether it was a GoCD Server version upgrade or the introduction of the 
reverse proxy.

-Chad

 

 

 

On Tue, Jan 17, 2023 at 10:32 PM Funkycybermonk mailto:chant...@gmail.com> > wrote:

Hello!

 

I thought I had posted this and apparently didn't finish it. If there is a 
duplicate, apologies, I couldn't find it today.

 

After upgrading to 22.3 and setting up the IIS reverse proxy, I can do 99% of 
things, but there are a few issues such as editing the xml file that will throw 
an error when saving unless I change back to http/8153. In the logs I see an 
error that the http origin header didn't match the request.base_url along with 
the following lines:

RE: [go-cd] Re: GoCD 22.3 does not appear to allow windows file paths for git urls

[chantryc]

UNC path cloning does work on Windows but I don’t know if its been all versions 
or just after a certain point. Its at least been working since ~2009 I think 
which is the oldest point I could quickly find that it was noted as being used. 
I don’t know the original version of GoCD we used but we’ve had 20.1 running 
for quite some time while trying to get an upgrade window. It did work in 20.5 
at the migration point for a quick test of the migration prior to going on to 
22.3 so I suspect 21.3 is the point it was affected. 

 

I can clone to/from and between UNC paths using “git clone 
\\domain\path\somefolder\repo  ” into the 
folder I’m in as well as between such as “git clone 
\\domain\path\somefolder\repo   
\\domain\path\otherfolder\repo  ”. I had a 
clean upgrade from 20.1 to 22.3 yesterday but 22.3 wouldn’t start unless I 
faked out the URL and after poking around in source I found that list of 
allow/disallow rules that gave me the idea of trying file instead of direct 
UNC. 

 

Using a stopwatch ([System.Diagnostics.Stopwatch]) there are obviously 
fluctuations in the time to clone from any source but locally using UNC I got 
27 seconds on my larger repo, using file:// was 22 and https from the repo 
source was 1 minute 50 seconds. I’m not sure either file:// or UNC are 
universally faster because on a smaller repo its about 5 seconds slower at 
times for file:// than UNC.

 

It might be worth a note in docs about UNC not working vs file:// although I’m 
not sure from looking at the isValidURL class whether windows file paths would 
work like d:\folder\repo. At this point I’m functional and able to proceed with 
finalizing our internal notes before going to production with 22.3 in ~3 weeks.

 

Thanks!

 

From: go-cd@googlegroups.com  On Behalf Of Chad Wilson
Sent: Wednesday, November 9, 2022 9:01 PM
To: go-cd@googlegroups.com
Subject: Re: [go-cd] Re: GoCD 22.3 does not appear to allow windows file paths 
for git urls

 

I am curious, does a UNC path work with `git clone` on the command line?

 

It's possible this happened as a side effect of strengthening the validation in 
21.3.0 (https://www.gocd.org/releases/#21-3-0) due to 
https://github.com/gocd/gocd/security/advisories/GHSA-xx28-8pr9-6xqh

 

On Thu, Nov 10, 2022 at 6:50 AM Funkycybermonk mailto:chant...@gmail.com> > wrote:

It appears that I am able to change it from a unc path to a file protocol path 
to get the slashes the other direction and it does work. I'm not sure there is 
a specific reason but it actually seems to shave about 5 seconds off the time 
to pull the resources in. 

 

If this isn't a concern for anything else, I think I'm ok, it just might be 
helpful to Windows installs if there is a note that UNC paths no longer work 
and to use file://path instead.

 

Thanks!

On Wednesday, November 9, 2022 at 3:15:12 PM UTC-6 Funkycybermonk wrote:

Hello!

 

It appears that on start, 22.2/22.3 at least try to validate the git urls in my 
cruise xml. The issue is that it doesn't seem to allow windows file or unc 
paths like . I can change them to something else 
temporarily but it appears that the xml validation will always fail. Is there a 
way to add alternate git path formats without a new build of the server? Or, if 
there is just an alternate way of legitimately addressing a unc path in GoCD in 
a different format it accepts. We can't pull it from outside every time because 
these run frequently and its a cost overhead for data being pulled in so it 
gets expensive over time. 

 

It appears to be tested using class isValidURL in UrlArgumentTest.java but the 
error is being thrown from ScmMaterialConfig.java I think.

 

Thanks!

-- 
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/862032f5-ba19-4d4b-8a2e-6ad542b96125n%40googlegroups.com
 

 .

-- 
You received this message because you are subscribed to a topic in the Google 
Groups "go-cd" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/go-cd/mR7oBDTPqtc/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAA1RwH-qm6uJa%3Dy-cQgm30BPfw7a1623NbWvNRWXrYJYWf7Ucw%40mail.gmail.com
 

 .

-- 
You received this message because you are subscribed to the Google Groups 
"go-cd" group.
To unsubscribe from 

RE: [go-cd] Issues with backups on Go 22.2 and PostgreSQL v12

[chantryc]

Sure! I’d be happy to drop it in and see if that works! I can double check on 
the folder creation that way as well. I haven’t entirely worked out building 
the package myself so if you have an installer I can run or just the files to 
replace and instructions on where they need to go I’m happy to give it a run. 

 

Thanks!

 

From: go-cd@googlegroups.com  On Behalf Of Chad Wilson
Sent: Wednesday, November 2, 2022 11:05 AM
To: go-cd@googlegroups.com
Subject: Re: [go-cd] Issues with backups on Go 22.2 and PostgreSQL v12

 

With a bit of quick pg_dump testing on Windows (via choco install 
postgresql12/choco install postgresql14) without actually integrating with 
GoCD) I can confirm the utility complains about the order of the positional 
(non-option) dbname arguments in ways that the same utility on MacOS does not. 
Only checked v12 and v14.

So it seems we need to fix something on the server here. I have a draft fix at 
https://github.com/gocd/gocd/pull/10982 which should be easy to get into the 
next 22.3.0 release (we were planning to release shortly anyway), especially if 
you are willing to help with sanity testing backups on your trial Windows setup 
you are working on. 

-Chad

 

On Wed, Nov 2, 2022 at 11:13 PM Chad Wilson mailto:ch...@thoughtworks.com> > wrote:

Technically speaking, the docs say the dbname without --dbname= should be the 
last argument after all connection options, which GoCD doesn't respect. 
Possibly pg_dump is more flexible on other OSes than Windows?

If you move "gocd" to the end of the command line you will probably find it 
works.


If you can raise an issue with the specific details to make it easy to 
reproduce (I don't work with Windows much, so the easier the better) at 
https://github.com/gocd/gocd/issues it can probably be fixed/addressed with 
`--dbname=` prefix to be unambiguous.

You could try other versions of pg_dump and see if the behaviour is different 
as well.

 

-Chad

 

On Wed, Nov 2, 2022 at 10:46 PM Funkycybermonk mailto:chant...@gmail.com> > wrote:

It looks like the file version is 12.0.12.0.  I'm using the version that 
shipped with the PostgreSQL 12 installer. I can downgrade to a lower PostgreSQL 
version if this is an issue with this release of pg_dump.

 

The message I get when constructing the command line using as-is from the logs 
is:

 

"C:\Users\removed>pg_dump --no-password --host=localhost --port=5432 
--username=removed gocd --file="C:\Program Files (x86)\Go 
Server\artifacts\serverBackups\backup_20221101-202201\db.gocd"
pg_dump: error: too many command-line arguments (first is "--file=C:\Program 
Files (x86)\Go Server\artifacts\serverBackups\backup_20221101-202201\db.gocd")
Try "pg_dump --help" for more information."

 

I can make it work by adding the --dbname= in front of the gocd value although 
the directory has to be created before the path from the logs will work. I'm 
assuming thats because the process failed in GoCD so the folder was removed as 
cleanup. Creating the folder results in a successful db.gocd backup file being 
created.

 

Thanks!

On Wednesday, November 2, 2022 at 8:58:17 AM UTC-5 ketanpad...@gmail.com 
  wrote:

What version of pg_dump are you using? According to 
https://www.postgresql.org/docs/current/app-pgdump.html, the command line 
string looks OK. But we've not tested this on windows.

 

- Ketan

 

 

On Wed, Nov 2, 2022 at 4:31 AM Funkycybermonk mailto:chan...@gmail.com> > wrote:

Hello!

 

New upgrade going from GoCD 20.1 to 22.2 and migrated to PostgreSQL v12 on 
Windows. Everything is now working properly but the backups were blowing up due 
to not being able to find pg_dump. I added the bin for PostgreSQL to the system 
path and the backup exits with a status code 1. I went back and checked the 
command and it looks like it might be blowing up because the dbname isn't 
defined with a parameter name. 

 

The executing bit is showing [pg_dump, --no-password, --host=localhost, 
--port=5432, --username=, gocd, --file=C:\Program Files (x86)\Go 
Server\artifacts\serverBackups\backup_20221101-215455\db.gocd] with environment 
{PGPASSWORD=}

 

The gocd bit in the middle appears to be the dbname but its not qualified as 
--dbname. Is that a bug or is there something I haven't configured properly? If 
I take that parameter string and run it in a command prompt with the commas 
removed it blows up on the parameters not matching up. Adding the --dbname= to 
that parameter works for me but I'm not sure if that should be required. 

 

I can roll back to H2 but I was hoping there would be a performance improvement 
and future-proofing if I went ahead with the migration now. If that doesn't 
make sense then I'm happy to stay with H2.

 

Thanks!

-- 
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+un...@googlegroups.com 

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

[chantryc]

That did help. It appears that starting in version 20.2 having those fields 
blank doesn’t allow it as *, it allows only localhost and %servername%. I added 
the cname url andthat seems to have worked. I think that is a solution 
honestly. I would have liked to be able  to allow multiple custom names so I 
can have a friendly direct-to-server as well as a reverse proxy but once in 
production its unlikely that the direct name will be needed without also having 
retrieved the server name as well to use for the url.

 

I appreciate the help on this! I think we can call this one solved and I’ll 
start a DB specific thread if my DB migration still has issues. I think I’ve 
done enough source crawling and reading documentation to be much better off in 
that area and worst case I’ll just H2>H2 to make it easier. 

 

Thanks to all involved for the help on solving this!

 

From: Aravind SV  
Sent: Tuesday, November 1, 2022 2:38 AM
To: Funkycybermonk ; go-cd 
Subject: Re: [go-cd] Issues with GoCD db.properties file and LDAP after upgrade 
to 20.4.

 

Hello,

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?

Hmm, I wonder if the site URL and secure site URL are set wrong, and the 
cookies are being set on the wrong domain? Worth checking.

 

 
https://docs.gocd.org/current/installation/configuring_server_details.html#configure-site-urls

Cheers,
Aravind

From:   Funkycybermonk
Subject: Re: [go-cd] Issues with GoCD db.properties file and LDAP after upgrade 
to 20.4.
To:   go-cd
Date: Mon, 31 Oct 2022 11:49:32 -0700 (PDT)

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 

RE: [go-cd] Job/task Success Status Recovery

[chantryc]

Thanks for the quick response!

 

I was pretty sure that was going to be the answer. I was already rewriting this 
morning for a try/catch/cleanup/repeat in anticipation of the confirmation.  I 
agree the second approach would be a last resort but all good suggestions. 

 

Thank you! 

 

From: go-cd@googlegroups.com  On Behalf Of Chad Wilson
Sent: Wednesday, September 21, 2022 7:11 AM
To: go-cd@googlegroups.com
Subject: Re: [go-cd] Job/task Success Status Recovery

 

I believe your understanding is correct - that you can't go back and change the 
earlier task to succeed.

 

 

I would consider incorporating your retry/correction steps into the original 
task with wrapping source controlled scripting, or wrap it with some kind of 
build automation tooling/task runner that can allow you to model retries or 
correction hooks so each task is self contained.

 

Either that, or make the original task return 0 exit code even on failure and 
have a subsequent task check it succeeded independently and attempt retry if 
not, with failure if it still fails (although I personally don't think the 
second approach is that great).

 

-Chad

 

On Wed, 21 Sep 2022, 20:01 Funkycybermonkey, mailto:chant...@gmail.com> > wrote:

Hello!

 

I'm curious if anyone is aware of a way to modify the status of a job based on 
subsequent tasks in that job. For example, in a stage I have a job that if a 
task fails, I have subsequent tasks that run on failure to correct the cause 
and automatically rerun the failed task again as a final task in that job. On 
success can it be triggered to go back to green? Or does it have to be an 
entire rerun of the job without any failed tasks to be considered a pass?

 

Ideally the reason for the failure would be corrected but that seems to be a 
bug in another software I'm calling so a nice short solution would be to do the 
followup tasks but then have the pipeline keep going if the followup tasks are 
a success.

 

I suspect the ability to run a task on failure is solely for cleanup, not 
recovery but I wanted to see if I was missing something.

 

Thanks!

-- 
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/f408b870-c769-49f2-8959-bd633fbe0a8en%40googlegroups.com
 

 .

-- 
You received this message because you are subscribed to a topic in the Google 
Groups "go-cd" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/go-cd/xWKXRZncp54/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAA1RwH-qQmTNbtLAAZydVruwirebEd1Myi5gNu_aJNRZSPqi0Q%40mail.gmail.com
 

 .

-- 
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/002c01d8cdc1%2400f38090%2402da81b0%24%40gmail.com.