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

[Funkycybermonk]

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/go-cd/1a7de3d6-8dae-4da0-b675-6d02ab885993n%40googlegroups.com.

Re: [go-cd] Preventing manual progressing of failed stages

[Chad Wilson]

To my knowledge there's nothing that allows that override by an admin/user
group, other than the admin or group admin or pipeline admin's implicit
ability to edit the pipeline config and remove the requirement from the
stage temporarily (if the pipeline is defined via UI/API rather than in an
external yaml, JSON, groovy config repo).

-Chad

On Tue, 1 Nov 2022, 10:59 hans.dush...@gmail.com, <
hans.dushanthaku...@gmail.com> wrote:

> 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
> 
> .
>

-- 
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/CAA1RwH-ApjcrF6fbDRcn-Ti-fWO4YMyJW6PFciBGWpiG1pN41A%40mail.gmail.com.

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

[Chad Wilson]

Good that you're unblocked on this part at least.

Since 20.2 involved the disabling of direct TLS support
 on the GoCD server itself
(unless you temporarily opt-in, which would be a bit pointless in your case
since it was completely removed in a later release you intend to upgrade
past), any direct to server comms would be HTTP-only on port 8153.

Assuming 8154 is disabled on your GoCD server, and you require TLS via your
reverse proxy (which is its core role) you might be able to get away with
only setting the secure site URL to your RP addressable name and leaving
the other one blank for the localhost/direct to server HTTP connections?

Speaking generally without having dug into GoCD specifics, generally the
way of handling this stuff when reverse proxied without server
configuration for proxied traffic is to rely upon reverse-proxy-set headers
such as X-Forwarded-Host/Port/Protocol or the standard Forwarded HTTP
header to determine the "real" URL but it does require some plumbing and
I'm not sure if all of GoCD's traffic routes do that consistently. Would be
interesting to know if your reverse proxy is setting/propagating those
standard headers.

-Chad


On Tue, Nov 1, 2022 at 11:58 PM  wrote:

> 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 

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] Issues with GoCD db.properties file and LDAP after upgrade to 20.4.

[Aravind SV]

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.



Cheers,
Aravind

-- 
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/m2tu3j3z1j.fsf%40arvindsv.com.