For more background on what is meant by "If user authentication is enabled", look here: https://db.apache.org/derby/docs/10.15/security/cseccsecure42374.html
bryan On Thu, Dec 1, 2022 at 6:24 AM fed <[email protected]> wrote: > > Another thing I don't understand is about shutdown, from the documentation, > adminguide, it says: > > https://db.apache.org/derby/docs/10.15/adminguide/tadminconfigshuttingdownthenetworkserver.html > > "Important: If user authentication is enabled, you must specify a valid Derby > user name and password; if the user authentication check fails, you'll see an > authentication error and the running server remains intact. Note that Derby > does not yet restrict the shutdown privilege to specific users: the server > can be shut down by any user on the server machine who presents valid > credentials." > > Which username and password ? > > from a single network server running I can access multiple databases, right? > Considering jdbc url I can access them in this way I suppose for example: > `jdbc:derby://localhost:1527/db/db1` > `jdbc:derby://localhost:1527/db/db2 > ... etc` > > if every one of them will have their own user/password (I am using NATIVE > authentication) so what password has to be specified on shutdown ? > > And testing it seems I can shutdown it even without providing any > user/password. > > Thanks for the help. > > > > > > On Thu, 1 Dec 2022 at 13:15, fed <[email protected]> wrote: >> >> Hi, >> >> As you suggested, the issue is the security manager, to be honest I am used >> to java security manager, I read and tested a bit to understand how it works. >> My initial setup was server service in a dir, let’s say /dir1 and database >> in another dir let’s say /dir2 so the dirs are distinct to each other. >> >> Considering version 10.15.2.0 running the server without security manager >> works: >> >> java -jar derbyrun.jar server -noSecurityManager start >> >> but reading from documentation I know it is not recommended and advisable so >> I want to use the security manager. >> >> So then I put my db dir inside the lib dir where derbyrun.jar and other jars >> are, so something like lib/db/mydb and running it with >> java -jar derbyrun.jar server start >> and I can access the db even using relative path on jdbc url, db/mydb. >> >> I am not used to derby in server mode, I read the documentation but sorry >> it’s not all clear to me how to use it. >> So from my test I suppose the recommended setup is to create a db dir inside >> lib and put all the dbs inside it ? lib/db/db1, lib/db/db2 etc ? right? >> >> Just as note I tested again with 10.12.1.1 and I found that forcing the >> security policy with the server template one (I suppose the default >> behaviour is changed with the newer version) it behaves the same like >> 10.15.2.0, I used: >> java >> -Djava.security.policy=/tmp/db-derby-10.12.1.1-bin/demo/templates/server.policy >> -jar derbyrun server start >> >> Thanks for the help. >> >> >> On Fri, 25 Nov 2022 at 21:02, Rick Hillegas <[email protected]> wrote: >>> >>> Check that your 10.15 classpath is correct. You need a couple more jar >>> files compared to previous releases. Your 10.15 server classpath must >>> contain the following jars: >>> >>> derby.jar >>> derbyshared.jar >>> derbytools.jar >>> derbynet.jar >>> >>> See >>> https://db.apache.org/derby/docs/10.15/adminguide/tadminappschangingyourclasspath.html >>> and >>> https://db.apache.org/derby/docs/10.15/publishedapi/org.apache.derby.server/module-summary.html >>> >>> >>> On 11/25/22 9:51 AM, Rick Hillegas wrote: >>> > This indicates that the server is running with a Java SecurityManager >>> > and that the policy file does not grant read permission on that >>> > file--and probably all files in the database directory. >>> > >>> > On 11/25/22 12:30 AM, fed wrote: >>> >> Hi, >>> >> >>> >> testing with 10.15.2.0 from derby.log, server side, it complains about a >>> >> read permission on service.properties, some part of the file: >>> >> >>> >> java.sql.SQLException: Impossibile avviare il database >>> >> '/home/user/db/' con >>> >> il caricatore di classi >>> >> jdk.internal.loader.ClassLoaders$AppClassLoader@277050dc. Per i >>> >> dettagli, >>> >> vedere l'eccezione successiva. >>> >> ... >>> >> Caused by: java.security.AccessControlException: access denied >>> >> ("java.io.FilePermission" "/home/user/db/service.properties" "read") >>> >> ... >>> >> ERROR XBM0C: Privilegio mancante per l'operazione 'exists' sul file >>> >> 'service.properties': access denied ("java.io.FilePermission" >>> >> "/home/user/db/service.properties" "read") >>> >> >>> >> >>> >> There are several errors like these ones but I have read permission >>> >> on this >>> >> file. >>> >> The user that starts the server is the same that owns the file, the >>> >> permissions on the file are 664. >>> >> >>> >> As I said, same setup but using 10.12.1.1 for the server, I have no >>> >> problems. >>> >> >>> >> Best Regards >>> >> -fed >>> >> >>> >> On Thu, 24 Nov 2022 at 19:52, Rick Hillegas <[email protected]> >>> >> wrote: >>> >> >>> >>> The SQLState indicates that the server was not able to boot the >>> >>> database. Look in the server-side derby.log to see if there is a >>> >>> detailed error message describing why the boot failed. >>> >>> >>> >>> On 11/23/22 4:42 PM, fed wrote: >>> >>>> Hi, >>> >>>> >>> >>>> Sorry for the late answer but I lost your reply. >>> >>>> >>> >>>> Two tests: >>> >>>> >>> >>>> I have a database updated to version 10.12.1.1, the server is running >>> >>> with >>> >>>> the 10.12.1.1 too and the client is using 10.12.1.1 too, the >>> >>>> connection >>> >>> is >>> >>>> OK, I can use this setup. >>> >>>> >>> >>>> But another test: >>> >>>> still the same database updated to version 10.12.1.1, the server is >>> >>> running >>> >>>> 10.15.2.0 so a newer version and the client is using 10.12.1.1: I have >>> >>>> problems in this case the client can't connect to the database with >>> >>>> this >>> >>>> error: >>> >>>> >>> >>>> Caused by: org.apache.derby.client.am.SqlException: DERBY SQL error: >>> >>>> ERRORCODE: 40000, SQLSTATE: XJ040, SQLERRMC: Impossibile avviare il >>> >>>> database '/home/user/some_db_path/' con il caricatore di classi >>> >>>> jdk.internal.loader.ClassLoaders$AppClassLoader@277050dc. Per i >>> >>> dettagli, >>> >>>> vedere l'eccezione successiva.::SQLSTATE: XBM0C >>> >>>> >>> >>>> Thanks for the help >>> >>>> >>> >>>> >>> >>>> >>> >>>> On Sun, 13 Nov 2022 at 15:26, Bryan Pendleton < >>> >>> [email protected]> >>> >>>> wrote: >>> >>>> >>> >>>>> I'm not aware of client-server version incompatibilities. Have you >>> >>>>> done any experiments with different versions? >>> >>>>> >>> >>>>> thanks, >>> >>>>> >>> >>>>> bryan >>> >>>>> >>> >>>>> On Thu, Nov 10, 2022 at 4:16 AM fed <[email protected]> wrote: >>> >>>>>> Hi, >>> >>>>>> >>> >>>>>> using derby with network server setup is there any problem if the >>> >>> server >>> >>>>> and the client are running on different java versions? >>> >>>>>> Still on this, considering the database created/updated with the >>> >>>>>> apache >>> >>>>> derby version that the client uses, is there any problem if the >>> >>>>> server >>> >>> will >>> >>>>> use a newer version of apache derby? >>> >>>>>> Thanks for the help >>> >>>>>> >>> >>>>>> -fed >>> >>> >>> >>> >>> > >>>
