Re: [bug-GNUnet] Can't specify different names for config file in project data
Ok, then I'm not sure how you expect this to work: if you do not give the code access to the configuration data (i.e. by telling it to load it from a different directory than where GNUnet was installed and also not providing the right configuration information in that directory), then obviously the logic will fail when it needs its configuration. Note that you can use GNUNET_CONFIGURATION_load* with the "right" path(s) to manually load either the GNUnet configuration data or your own applications' configuration data (if they are in different locations). However, without such manual action on your part, libgnunetutil will by design only load the configuration data from the one location that is configured via the ProjectData mechanism. Does this help? On 9/10/19 9:41 PM, Alessio Vanni wrote: > Sorry for the late reply. I didn't see there was a reply to the report > (I'm not subscribed to this list... I check the archives from time to > time though.) > >> This shouldn't be the case, as GNUnet picks up the (default) service >> contact information from a the share/gnunet/config.d/ directory. >> >> Also, when I change the value, everything still works for me. What is >> the error message you are seeing (if any)? > > The problem is in 3rd-party applications. GNUnet itself correctly reads > its config files from the correct directories. However, if the > GNUNET_OS_ProjectData structure holds different values, the application > doesn't work. > > The main problem is that it can't connect to GNUnet services, so the > error is that `GNUNET_CLIENT_connect' returns NULL when making a > connection. > > For a concrete error message, using `GNUNET_IDENTITY_ego_lookup' (which > makes an implicit connection to the IDENTITY service) when .config_file > and .user_config_file are different from "gnunet.conf" and > "~/.config/gnunet.conf" respectively, it fails with the following > message: > > ERROR Assertion failed at identity_api_lookup.c:202. > > The line in question is a `GNUNET_break' called when > `GNUNET_CLIENT_connect' returns NULL. > > The error does not happen if the configuration file (either one, as long > as it exists) is the same as GNUnet itself. > > I attached a minimal program for testing this issue. It simply calls > `GNUNET_IDENTITY_ego_lookup'. If it successfully connects, it will > print wether or not the ego "test-ego" exists; otherwise, it will fail > with the above message. > > Thanks, > A.V. > > > ___ > Bug-GNUnet mailing list > Bug-GNUnet@gnu.org > https://lists.gnu.org/mailman/listinfo/bug-gnunet > signature.asc Description: OpenPGP digital signature ___ Bug-GNUnet mailing list Bug-GNUnet@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnunet
Re: [bug-GNUnet] Can't specify different names for config file in project data
Christian Grothoff writes: > Ok, then I'm not sure how you expect this to work: if you do not give > the code access to the configuration data (i.e. by telling it to load it > from a different directory than where GNUnet was installed and also not > providing the right configuration information in that directory), then > obviously the logic will fail when it needs its configuration. > > Note that you can use GNUNET_CONFIGURATION_load* with the "right" > path(s) to manually load either the GNUnet configuration data or your > own applications' configuration data (if they are in different > locations). However, without such manual action on your part, > libgnunetutil will by design only load the configuration data from the > one location that is configured via the ProjectData mechanism. > > Does this help? I'm not sure if I understood correctly what you mean, so let me list what I know about how configuration works. It might be wrong and that's why I'm doing this. When I define the ProjectData structure, I specify that I want my application to look for a certain configuration file. Because I want this file to be specific to my application, I don't use the GNUnet's file, but something else (say, "test-program.conf" and "~/.test-program.d/config") Before reading that file (if it exists), GNUnet searches a standard location for a default configuration, which is the "config.d" directory inside the GNUNET_OS_IPK_DATADIR directory. That directory is found by using the ".project_dirname" field of the ProjectData structure, so if that field is "test-program", the GNUNET_OS_IPK_DATADIR directory would be "share/test-program/config.d/". The configuration loader will load any file that is inside that directory and then it will load the config file provided by ".config_file" or ".user_config_file". Because that directory is not GNUnet's directory, anything specific to GNUnet is not loaded. The problem with this is that the application is then unable to find the port/socket needed to connect with GNUnet's services. Calling the loader on the config files specified by the default ProjectData or simply not changing those two field in the structure does not really solve it: if the file is empty (the tutorial on the website itself says it's fine to have an empty gnunet.conf) the default values are still not loaded as they are located in "share/gnunet/config.d" which is never scanned by GNUnet. Ultimately what I'm expecting is that on initialization the application loads GNUnet's settings (mainly to find the services' port/sockets) and then its own settings. Is that a wrong assumption to make? Thanks, A.V. ___ Bug-GNUnet mailing list Bug-GNUnet@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnunet
Re: [bug-GNUnet] Can't specify different names for config file in project data
On 9/11/19 6:00 PM, Alessio Vanni wrote: > Christian Grothoff writes: > >> Ok, then I'm not sure how you expect this to work: if you do not give >> the code access to the configuration data (i.e. by telling it to load it >> from a different directory than where GNUnet was installed and also not >> providing the right configuration information in that directory), then >> obviously the logic will fail when it needs its configuration. >> >> Note that you can use GNUNET_CONFIGURATION_load* with the "right" >> path(s) to manually load either the GNUnet configuration data or your >> own applications' configuration data (if they are in different >> locations). However, without such manual action on your part, >> libgnunetutil will by design only load the configuration data from the >> one location that is configured via the ProjectData mechanism. >> >> Does this help? > > I'm not sure if I understood correctly what you mean, so let me list > what I know about how configuration works. It might be wrong and that's > why I'm doing this. > > When I define the ProjectData structure, I specify that I want my > application to look for a certain configuration file. Because I want > this file to be specific to my application, I don't use the GNUnet's > file, but something else (say, "test-program.conf" and > "~/.test-program.d/config") That's already not the suggested approach. If you want to interact with GNUnet because you are working on top of GNUnet, you should not override _either_ value. GNU Taler overrides these values, but GNU Taler does _not_ want to interact with GNUnet services! What you should do -- if you want to have your "own" configuration (and use the libgnunetutil configuration parser) -- is to load your configuration using GNUNET_CONFIGURATION_create/load APIs providing your own application paths explicitly there. However, that configuration object must then not be used to interact with GNUnet services. So you'd basically have two configuration handles: one or your own application (which you'd use internally), and one which you'd pass to GNUnet APIs. Now, if you do not merely want to use your own configuration, but also use the GNUnet *service* API, then you _may_ override ProjectData to use your own configuration location. However, if you then want to interact with GNUnet services, you _MUST_ make a backup of the "old" project data (or somehow have some other means of determining the "correct" GNUnet configuration location, i.e. using the GNUNET_OS_install_path() API) and again create/load the GNUnet configuration when creating a configuration handle to interact with GNUnet services. > Ultimately what I'm expecting is that on initialization the application > loads GNUnet's settings (mainly to find the services' port/sockets) and > then its own settings. Is that a wrong assumption to make? It's not wrong, just if you decided to have two configuration locations, then you must manage two configuration objects and pass the "right" one at the right time. Managing this is not something libgnunetutil can do for you. signature.asc Description: OpenPGP digital signature ___ Bug-GNUnet mailing list Bug-GNUnet@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnunet
