I am having some problems changing the admin password via CLI. My steps are:
Run Stardog
I change the admin password with stardog-admin
I tried to do anything else afterwards: "Authentication failed". I cannot even stop the server! It is locked with "Authentication failed"
So by reading the manual I reinstall Stardog and attempt to start with: STARDOG_SERVER_JAVA_ARGS="-Xmx.... -Dstardog.passwd.file=/home/user/sdpass"
And the file looks like: *:*:*:admin:secret
I repeat the steps (run Stardog, change admin password, try something else) and again "Authentication failed". The logs shows no trace of this property, whereas they show the values of the memory I set (-Xmx...).
The manual is not very specific about how to set this "system property". Obviously it cannot be set in the same way as other so-called system properties in the manual (like JAVA_ARGS), so I assumed it has to be set via "-D...". Am I setting the property incorrectly? Also, I am not sure how this will work since if the property is used when the admin password has not been changed yet, Stardog will likely complain to start.
If Stardog finds a password file in the default location (~/.sdpass for *nix systems, ~\Application Data\stardog for Windows), it will use that one regardless of the value of stardog.passwd.file.
That said, you are trying to set the property correctly. I would use STARDOG_JAVA_ARGS instead of STARDOG_SERVER_JAVA_ARGS, however, so that all commands run in that environment (not just server start) are aware of the property value.
You are correct that it will probably complain when the password hasn't been changed yet. You can get around this by passing the -P flag to any command you run, which will prompt for a password. Also, starting the server will be fine, since this isn't an action that requires authentication.
I knew about .sdpass but I cannot use it since the user running Stardog has no login and no home.
I think the trick was to use STARDOG_JAVA_ARGS instead. It is perhaps worth it to write this in the manual, since it can be a bit confusing as to where to define the system property.
Starting the server could be done as you said without the authentication being checked, so this allowed me to set the pw file in advance and change the admin password as the next thing. This behaviour was very appreciated, since otherwise it could be very toublesome to run commands without getting "locked out" (prompted for a password was not an option since I wanted to run an automtic script with no iteration).
Sorry - I have been having problems with this afterwards. I am not sure why, but the sdpass file does not seem to be in use. How can I verify this?
I tried to login via http://....:5820 unsuccessfully. Then I tried to run a command via CLI with same results. The only way to run the command was specifying the -p option and the password manually, and this way it was successful. That is why I am thinking the file is not being accessed.
I am not sure this will be a bug in the GUI. I have manually start Stardog some other way and finally I managed to get sdpass used (I still have the problem I described in the previous post, though). However, now if I try to access via GUI I get the user/password message all the time. I write my details and it loads part of the GUI and I am asked again. I input details again and nothing new happens. I cancel and then something else loads and I am asked again for credentials. The process repeats until the GUI is partially loaded.
For the CLI problems, you should still be using STARDOG_JAVA_ARGS to ensure that the sdpass file is seen for ALL CLI commands and not just server start.
As for the GUI, once you've restarted the server and cleared your browser cache, do you see the same issue? I always run the console in incognito mode (when debugging, anyway), as Chrome likes to cache everything.
Yes, my mistake when I copied it (I am also using STARDOG_SERVER_JAVA_ARGS). I am using STARDOG_JAVA_ARGS for the -Dstardog.passwd.file. It is strange because the other variables (STARDOG_HOME for example) are been retrieved correctly, but this one does not seem to be got. I tried to use "jcmd" to see if the variable was there but it wasn't
As for the GUI - you were right, incognito worked.