Hiya On Thu, Oct 27, 2022 at 8:26 AM Funkycybermonk <[email protected]> wrote:
> 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. > GoCD 22.2.0 shouldn't have changed the install location on Windows, especially not for upgrades. It just corrects some permissions, but shouldn't affect you if you are installing in the default Program Files location which it looks like. The docs might be misleading about which Prog Files variant it goes into for various Windows types. In any case, if the behaviour you see is/was the same between GoCD 20.5.0 (post db migration) and 22.2.0 then we can probably rule out any change for Windows permissions as a cause of your challenges. In your case, post-20.5.0 migration, are you trying to use a migrated inbuilt H2 database, or a separate Postgres/Mysql install? - Generally speaking, if you are not trying to either override some H2 configuration *nor* use an external DB, config\db.properties doesn't exist and isn't required. - That error message is just a warning. It doesn't mean there is a problem, unless you are expecting it to use it, to know how to connect to an external DB. - The path should be relative to the working directory which should be set by the wrapper at startup. if you want to confirm, that should be logged within logs\go-server-wrapper.log (search for "Working directory") before it launches GoCD. Nevertheless it's weird if you have config\db.properties and it's not working. Perhaps you can check the permissions on the file and see if there is anything unusual, or different than, say a "known good" config that is in the same folder, e.g config\config.xml. Assuming you are running GoCD via a windows service with the default user account of "Local System", it should be able to see the file. Having said all this, I am not sure I understand what actually happens with your GoCD server. Does it fail to start? it starts, but with a new/fresh local file DB rather than what you expect? It's missing data that you expect to be there? If there are database issues, I'd have thought it might not be wise to move to the next step of checking LDAP before ensuring database stuff is OK..... > > 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 `<deleted>` 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. > Unfortunately that doesn't tell us too much. :( What this looks like is a configuration problem with the authorization config or an "unknown user"; it has authenticated the user, but the GoCD server isn't allowing that user to login. Do you have "Allow only known users to login" in your Domain-LDAP auth config? *If so*, is the user you are logging in as listed and enabled in Users Management? The allowed/permitted users and roles are persisted in the DB (or dynamically added if that option is unchecked) so if you have issues with GoCD connecting to the right DB it might not have loaded the previously "allowed" users you expect - and thus maybe best to ensure the DB is in the right state first? -Chad -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/CAA1RwH_41SFPdJ_Lnn_bJqv%2B%3DUNpGOf0DrXg9NnPQnMsWfah0A%40mail.gmail.com.
