My favorites | Sign in
Project Home Downloads Wiki Issues Source
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 2781: Re-init'ing a Gerrit site prevents first-login administrator promotion
3 people starred this issue and may be notified of changes. Back to list
Status:  Duplicate
Merged:  issue 1228
Owner:  ----
Closed:  Oct 4


Sign in to add a comment
 
Reported by chris.ma...@wandisco.com, Jul 17, 2014
************************************************************
***** NOTE: THIS BUG TRACKER IS FOR GERRIT CODE REVIEW *****
***** DO NOT SUBMIT BUGS FOR CHROME, ANDROID, INTERNAL *****
***** ISSUES WITH YOUR COMPANY'S GERRIT SETUP, ETC.    *****
***** THOSE ISSUE BELONG IN DIFFERENT ISSUE TRACKERS!  *****
************************************************************

Affected Version: 2.8.5, 2.9-rc2

I've been writing an integration test framework that starts up a Gerrit instance, configures it, and uses it to run tests. Instead of automating stepping through the init wizard, I run it in with --batch and --no-auto-start, edit the config file it generates to switch to a PostgreSQL database + DEVELOPMENT_BECOME_ANY_ACCOUNT, and re-do the init step with this new config file, so that the database structure is now generated in PostgreSQL instead of H2.

When this instance of Gerrit is started up however, it fails to promote the first created user to the Administrators group, instead giving a stack trace (below) and responding with "Server error" in the UI. Reloading the page allows a new user to be created, but this user is not made a part of the admin group. Even manually making the entry in account_group_members between the new user and the Administrators group and restarting the service is not enough to grant Admin permissions.

What steps will reproduce the problem?
1. Init a Gerrit instance:

Dir.chdir(@gerrit_root) do
  Utils.run("java -jar #{$GERRIT_WAR} init -d ./ --batch --no-auto-start")
end

2. Modify the Gerrit config to use postgresql instead
3. Reinit Gerrit as before
4. Start the service and try to login.

What is the expected output? What do you see instead?

I expect my first user to become an Administrator. Instead I get a server error, and subsequently all users created are unprivileged, leading to a useless install. The following stack trace is in the logs:

[2014-07-17 20:21:08,276] INFO  com.google.gerrit.pgm.Daemon : Gerrit Code Review 2.8.5 ready
[2014-07-17 20:21:23,950] WARN  org.eclipse.jetty.servlet.ServletHandler : /login/
java.util.NoSuchElementException
	at java.util.ArrayList$Itr.next(ArrayList.java:834)
	at com.google.gerrit.server.account.AccountManager.create(AccountManager.java:293)
	at com.google.gerrit.server.account.AccountManager.authenticate(AccountManager.java:116)
	at com.google.gerrit.httpd.auth.become.BecomeAnyAccountLoginServlet.create(BecomeAnyAccountLoginServlet.java:268)
	at com.google.gerrit.httpd.auth.become.BecomeAnyAccountLoginServlet.doPost(BecomeAnyAccountLoginServlet.java:91)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:641)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
	at com.google.inject.servlet.ServletDefinition.doServiceImpl(ServletDefinition.java:278)
	at com.google.inject.servlet.ServletDefinition.doService(ServletDefinition.java:268)
	at com.google.inject.servlet.ServletDefinition.service(ServletDefinition.java:180)
	at com.google.inject.servlet.ManagedServletPipeline.service(ManagedServletPipeline.java:93)
	at com.google.gerrit.pgm.http.jetty.GetUserFilter.doFilter(GetUserFilter.java:76)
	at com.google.gwtexpui.server.CacheControlFilter.doFilter(CacheControlFilter.java:70)
	at com.google.gerrit.httpd.RunAsFilter.doFilter(RunAsFilter.java:113)
	at com.google.gerrit.httpd.AllRequestFilter$FilterProxy$1.doFilter(AllRequestFilter.java:64)
	at com.google.gerrit.httpd.AllRequestFilter$FilterProxy.doFilter(AllRequestFilter.java:57)
	at com.google.gerrit.httpd.RequestContextFilter.doFilter(RequestContextFilter.java:75)
	at com.google.inject.servlet.ManagedFilterPipeline.dispatch(ManagedFilterPipeline.java:120)
	at com.google.inject.servlet.GuiceFilter$1.call(GuiceFilter.java:132)
	at com.google.inject.servlet.GuiceFilter$1.call(GuiceFilter.java:129)
	at com.google.inject.servlet.GuiceFilter$Context.call(GuiceFilter.java:206)
	at com.google.inject.servlet.GuiceFilter.doFilter(GuiceFilter.java:129)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1307)
	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:453)
	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:229)
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1072)
	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:382)
	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1006)
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
	at org.eclipse.jetty.server.handler.RequestLogHandler.handle(RequestLogHandler.java:67)
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
	at org.eclipse.jetty.server.Server.handle(Server.java:365)
	at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:485)
	at org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:937)
	at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:998)
	at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:856)
	at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)
	at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
	at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:627)
	at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:51)
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
	at java.lang.Thread.run(Thread.java:744)


Please provide any additional information below.

I've tracked this down to the All-Projects.git repo. It looks like when the site is re-initialized to a new database, it writes the Administrator group UUID as 1d646d82416a37edf07e5cd01e771d1fc3982736. But in the All-Projects.git repo, the group file is as below:

# UUID                                  	Group Name
#
0b10af55d9aa9ffda9c51b547c1154577a5e975c	Non-Interactive Users
1d646d82416a37edf07e5cd01e771d1fc3982736	Administrators
56a02fc626ae13cee1e7e6019a4dd008419d3acb	Administrators
98ebdf32e6c71858462b1c242e295bde65cad8e3	Non-Interactive Users
global:Anonymous-Users                  	Anonymous Users
global:Project-Owners                   	Project Owners
global:Registered-Users                 	Registered Users

Going through the AccountManager.create() function in a debugger, the attempt to promote the first user account fails because it's looking for UUID 56a02fc626ae13cee1e7e6019a4dd008419d3acb, which does not exist in the database.

The workaround for me was to remove the All-Projects.git repo before doing the re-init with the new settings.
Aug 25, 2014
#1 l.bigonv...@gmail.com
I guess this is more or less a duplicate of #1228 ?
Aug 26, 2014
#2 chris.ma...@wandisco.com
Yes, looks like it, thanks! Didn't find that issue in my original search.
Oct 4, 2015
Project Member #3 David.Os...@gmail.com
(No comment was entered for this change.)
Status: Duplicate
Mergedinto: 1228
Sign in to add a comment

Powered by Google Project Hosting