The authentication.properties warning is completely meaningless. Don’t worry about that.
The admin/admin password is actually set up in step 7 prior to the XML import of the field groups:
StoreXML -project PROJECT_NAME -l security/security.xml -allowDataDeletion true
That creates the admin and guest user accounts.
--
You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/xnat_discussion/-/NplbtI6vpr8J.
To post to this group, send email to
xnat_di...@googlegroups.com.
To unsubscribe from this group, send email to
xnat_discussi...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/xnat_discussion?hl=en.
John
You have to stick with admin/admin for the installation OR you can change the values set in the security.xml file referenced in the StoreXML command. What most people do is just use admin/admin to get the system bootstrapped, then log in with that account, create a new admin account with a different name and a sound password, then deactivate the default admin account. If you’ve already run step 7, then you’ve got the admin account set up, so I’d just go with that, meaning that in step 8 the –u and –p options both take the value admin. Once the server’s up and going, log in as admin/admin, go to Administer->Users, create a new admin user (e.g. jmcleanAdmin), log out, log back in with your new admin account, and deactivate the default admin account.
Of course, if you’re just setting up a development instance to tinker with, you’re fine leaving the default admin account on there for ease of use. Anything accessible to the outside or with real research data should be better secured however.
I would suggest completely dropping the database at this point. It’s pretty clear you don’t have the admin role in the database, so it’s hard to guess what state it’s in. I’d GUESS (OK, so it’s not so hard to guess; but it would be hard to bet, as in, this guess is worth as much as you’ve paid for it J ) that you have the database schema installed but no data in it. So you could probably run StoreXML, get your security set-up initialized, and you’d be fine. But I’m not sure about that and it’s fairly easy to drop the database, re-create the database, and re-run the database script to initialize the schema. So it’d be something like this:
dropdb –U xnat xnat
createdb –U xnat xnat
psql –U xnat –f sql/xnat.sql
StoreXML -l security/security.xml -allowDataDeletion true
A couple notes on this:
· Make certain that Tomcat is not running during any of this, but especially not when you are running StoreXML (actually, you probably wouldn’t be able to drop the database if Tomcat was running).
· The “No authentication.properties file…” warning is nothing to worry about. It’s a standard message from one of the libraries as it tries to see if you have set up something to override the default authentication method.
Give that a try and let me know how it turns out.
I’m pretty psyched on the ansible-xnat playbook. We’ll pull it and test it out here real soon!
Sr. Programmer/Analyst
Neuroinformatics Research Group
Washington University School of Medicine
To unsubscribe from this group and stop receiving emails from it, send an email to xnat_discussi...@googlegroups.com.
To post to this group, send email to
xnat_di...@googlegroups.com.
Visit this group at http://groups.google.com/group/xnat_discussion.
For more options, visit https://groups.google.com/d/optout.
An error has occurred. Please contact your IT staff or the application logs for more information. |
...