[go-cd] LDAP Group Authentication/Roles/Permissions
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.
[go-cd] Agents going offline randomly on 22.3
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 Agent 01" "Go Agent 02" etc.: 2023-04-03 18:46:28,930 INFO [scheduler-3] SslInfrastructureService:78 - [Agent Registration] Starting to register agent. 2023-04-03 18:46:28,930 INFO [scheduler-3] SslInfrastructureService:88 - [Agent Registration] Fetching token from server. 2023-04-03 18:46:28,932 ERROR [scheduler-3] TokenRequester:59 - Received status code from server 409 2023-04-03 18:46:28,933 ERROR [scheduler-3] TokenRequester:60 - Reason for failure A token has already been issued for this agent. 2023-04-03 18:46:28,933 ERROR [scheduler-3] SslInfrastructureService:106 - [Agent Registration] There was a problem registering with the GoCD server. java.lang.RuntimeException: A token has already been issued for this agent. I have tried to see if I could recreate the token and guid files but I can't seem to get them to be accepted when I think their values are correct. If there is a way to recreate the guid and token from the PostgreSQL server I can do that but I haven't found anything so far that seems to work for recreating those. Is there any reason that the agent would register and then lose its registration that we can try to avoid? Over the last month or two we've lost registration and set agents back up roughly 50-80 times across all areas. Thanks in advance for any assistance! -- 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/b5b7ee4f-d21a-41a5-8162-3c883ae01542n%40googlegroups.com.
[go-cd] Re: Policies and Roles Issues
Making progress! I found a link in the console that explained attaching roles to pipelines which works, but I'd like to be able to say that I want a user to have permissions on a pipeline group through a role, but I only want them to run pipelines with TEST in the name and not and PROD pipelines. In the role I've tried adding deny to administer * * but the role permission on the pipeline group doesn't get modified. Is this just a fringe case we've put ourselves into and its not possible to manage things in this way? We've been using pipeline groups to contain all pipelines using a particular template type so PROD and TEST both are in the same pipeline group. If this isn't possible we can probably just split our groups out into 2x with a prod and dev/test group separately. I'm just confused on what I can and can't do with roles since its not a centrally managed feature but the roles can be reused for membership. Thanks! On Tuesday, March 21, 2023 at 10:29:01 AM UTC-5 Funkycybermonk wrote: > Hello! > > I'm sure I'm missing something simple, but I'm trying to lock down access > to certain tasks. We'll have some temporary users accessing our system and > I want to control what they can and can't do. I get the whole allow/deny > and I'm hoping that the View/Administer will be flexible enough to let me > limit what users can do to pipelines, but my initial test goal is to have a > working permissions set that does anything with pipelines. > > when I set a system administrator everyone gets their permissions dropped > as expected. But once I start adding them to a role containing a policy > that says for example Allow - Administer - Environments - *, I get the > ability as that user to see all environments but I can't see pipelines in > those environments. > > Setting Allow - Administer - All - * also doesn't let me see pipelines. > > How can I use roles/policies to give users permissions to basic items in > the system such as: I want a user to be able to run pipelines containing a > certain wildcarded name filter or I want them to be able to view all but > only execute certain environments, say only pipelines assigned in the > environment labeled TEST. > > The documentation doesn't give specific cases that are helpful in this > case. For example it says that Admnister on UI gives list, create, update, > delete, agent status and elastic profiles usage but the closes I can see in > the policy is the allow administer * * which doesn't let my user see any > pipelines. > > I'm running 22.3 with LDAP as my authentication provider if that > helps/affects anything. > > Any tips on how to get permissions set up to filter what can and can't be > accessed by non-systemadmins? > > 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/4dbc8c4f-ad7e-444e-9113-f85c358b87den%40googlegroups.com.
[go-cd] Policies and Roles Issues
Hello! I'm sure I'm missing something simple, but I'm trying to lock down access to certain tasks. We'll have some temporary users accessing our system and I want to control what they can and can't do. I get the whole allow/deny and I'm hoping that the View/Administer will be flexible enough to let me limit what users can do to pipelines, but my initial test goal is to have a working permissions set that does anything with pipelines. when I set a system administrator everyone gets their permissions dropped as expected. But once I start adding them to a role containing a policy that says for example Allow - Administer - Environments - *, I get the ability as that user to see all environments but I can't see pipelines in those environments. Setting Allow - Administer - All - * also doesn't let me see pipelines. How can I use roles/policies to give users permissions to basic items in the system such as: I want a user to be able to run pipelines containing a certain wildcarded name filter or I want them to be able to view all but only execute certain environments, say only pipelines assigned in the environment labeled TEST. The documentation doesn't give specific cases that are helpful in this case. For example it says that Admnister on UI gives list, create, update, delete, agent status and elastic profiles usage but the closes I can see in the policy is the allow administer * * which doesn't let my user see any pipelines. I'm running 22.3 with LDAP as my authentication provider if that helps/affects anything. Any tips on how to get permissions set up to filter what can and can't be accessed by non-systemadmins? 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/1582fc8d-5b93-4fa9-b098-9453b78e33ean%40googlegroups.com.
[go-cd] Issues with saving xml on secure url with reverse proxy
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: *ActionController::InvalidAuthenticityToken (ActionController::InvalidAuthenticityToken): actionpack (6.1.7) lib/action_controller/metal/request_forgery_protection.rb:211:in `handle_unverified_request'actionpack (6.1.7) lib/action_controller/metal/request_forgery_protection.rb:243:in `handle_unverified_request'actionpack (6.1.7) lib/action_controller/metal/request_forgery_protection.rb:238:in `verify_authenticity_token'* I'm not sure how to resolve the issue since everything generally works. I can do my updates over 8153 but it seems a little backwards to have to authenticate on an unsecure channel to make a change that I'm not trusted to make because I might be forging the token. Any ideas on how I can get around this? I'd think it was the reverse proxy but it all works properly outside this, as far as I can tell. And I'm doing the reverse proxy straight out of the Microsoft setup instructions/recommendations so nothing fancy there. 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/8c5c3abc-ef8d-4e56-9900-79773be9627fn%40googlegroups.com.
[go-cd] Re: GoCD 22.3 does not appear to allow windows file paths for git urls
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.
[go-cd] GoCD 22.3 does not appear to allow windows file paths for git urls
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/772a7604-bb58-4cfd-be7e-8481109c3073n%40googlegroups.com.
Re: [go-cd] Issues with backups on Go 22.2 and PostgreSQL v12
Backup works great! Do you know an eta on the release version or is this the version that will be rolled to release? I'm just weighing time vs using H2 until this is released for my upgrade window. Thanks!! On Thursday, November 3, 2022 at 3:13:26 AM UTC-5 Chad Wilson wrote: > Great, thanks Chantry! > > An experimental code-signed server installer version is available at > https://download.gocd.org/experimental/binaries/22.3.0-15295/win/go-server-22.3.0-15295-jre-64bit-setup.exe > > (check experimental tab here <https://www.gocd.org/download/#windows> if > you want to verify checksums etc) > > The Windows installers allow upgrades but prevent downgrades (perhaps for > some historical reason I am not aware of), so keep that in mind. There > aren't any DB or config.xml format changes in this release in any case so > should have strong backward compatibility with your 22.2.0 installation, > and agents will auto-upgrade/downgrade where necessary to match the server > version so there should be no need to also install an experimental agent > version. > > You can preview the release notes at > https://gocd.github.io/pr-review.gocd.org/pr-1416/releases/ if you have > any concerns about the other included changes since the 22.2.0 you are > testing with. > > -Chad > > > On Thu, Nov 3, 2022 at 1:39 AM wrote: > >> 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...@googlegroups.com *On Behalf Of *Chad >> Wilson >> *Sent:* Wednesday, November 2, 2022 11:05 AM >> *To:* go...@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 >> 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 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 &g
Re: [go-cd] Issues with backups on Go 22.2 and PostgreSQL v12
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 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/go-cd/1a7de3d6-8dae-4da0-b675-6d02ab885993n%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/go-cd/1a7de3d6-8dae-4da0-b675-6d02ab885993n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>
--
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/991c4de4-b112-4fc9-a8ed-4a8e3a2bdd3an%40googlegroups.com.
[go-cd] Issues with backups on Go 22.2 and PostgreSQL v12
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] Issues with GoCD db.properties file and LDAP after upgrade to 20.4.
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 &g
Re: [go-cd] Issues with GoCD db.properties file and LDAP after upgrade to 20.4.
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
[go-cd] Issues with GoCD db.properties file and LDAP after upgrade to 20.4.
Hello! I'm working on an upgrade path from 20.1 through 20.4 and a db migration up to 22.2. A long path and a lot of complicated things changing. The issues started with 20.4 and after a couple of hours of work I decided to go for broke and push through to 22.2. It worked but didn't improve anything. I feel like something relatively simple is going on but I am missing something and not finding it. I'm getting an error on service start "ConnectionManager:117 - The file config\db.properties specified by `go.db.config` does not exist." The file db.properties does exist in the config folder but I'm unable to see what the path is that its looking for prior to config. My installation folder after the two upgrade stages is still "C:\Program Files (x86)\Go Server" and I don't know if that means something is looking in the wrong place or not. I expected 22.2 to migrate it to "C:\Program Files\Go Server" from reading the documentation. I also have an issue with LDAP successfully authenticating and logging a success but always sending me back to login. I have removed authentication temporarily to let me work on troubleshooting but still haven't found a solution. The LDAP log shows: 2022-10-27 00:22:57,095 INFO [Thread-79] LdapPlugin:72 - Loading plugin null version 2.2.1-168 2022-10-27 00:22:57,231 ERROR [Thread-79] LdapPlugin:127 - Error while executing request go.plugin-settings.get-configuration com.thoughtworks.go.plugin.api.exceptions.UnhandledRequestTypeException: This is an invalid request type :go.plugin-settings.get-configuration Followed by 2022-10-27 00:23:38,205 INFO [qtp1522792394-33] LdapPlugin:72 - [Authenticate] User `` successfully authenticated using auth_config: Domain-LDAP I'm sort of wondering if something doesn't know where everything is at and is trying to load from incorrect locations but this is the test run for an upgrade on several systems that I can't do a clean wipe/restart on. Any ideas? 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/59b52e30-b0c2-4f3b-8e78-02d272fef539n%40googlegroups.com.
