Re: [bug-GNUnet] Can't specify different names for config file in project data

2019-09-11 Thread Christian Grothoff
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


Re: [bug-GNUnet] Can't specify different names for config file in project data

2019-09-11 Thread Alessio Vanni
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

2019-09-11 Thread Christian Grothoff
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

2019-09-10 Thread Alessio Vanni
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.

#include 
#define SOCKTYPE int
#define FDTYPE int

#include 
#include 

static struct GNUNET_OS_ProjectData test_pd = {
 .libname = "test",
 .project_dirname = "test",
 .binary_name = "test-config",
 .env_varname = "TEST_PREFIX",
 .base_config_varname = "TEST_CONFIG",
 .bug_email = "",
 .homepage = "",
 .config_file = "test.conf",
 .user_config_file = "/tmp/test.conf",
 .version = "1.0",
 .is_gnu = 0,
 .gettext_domain = "test",
 .gettext_path = NULL,
};

static const struct GNUNET_CONFIGURATION_Handle *cfg = NULL;

static void
ego_lookup(void *cls, const struct GNUNET_IDENTITY_Ego *ego) {
 if (ego == NULL) {
	  GNUNET_log(GNUNET_ERROR_TYPE_INFO, "test-ego does not exist\n");
 } else {
	  GNUNET_log(GNUNET_ERROR_TYPE_INFO, "test-ego exists\n");
 }
 GNUNET_SCHEDULER_shutdown();
}

static void
run(void *cls, char *const *args, const char *cfgname,
const struct GNUNET_CONFIGURATION_Handle *c) {
 GNUNET_log_setup("test-config", "INFO", NULL);
 
 cfg = c;

 if (GNUNET_IDENTITY_ego_lookup(cfg, "test-ego", _lookup, NULL) == NULL) {
	  GNUNET_log(GNUNET_ERROR_TYPE_ERROR, "Error with ego lookup\n");
	  GNUNET_SCHEDULER_shutdown();
 }
}

int
main(int argc, char *argv[]) {
 const struct GNUNET_GETOPT_CommandLineOption opts[] = {
	  GNUNET_GETOPT_OPTION_END,
 };
 
 GNUNET_OS_init(_pd);

 return (GNUNET_PROGRAM_run(argc, argv, "test-config",
"test", opts, , NULL)
	 != GNUNET_OK);
}
___
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

2019-09-04 Thread Christian Grothoff
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)?

On 9/1/19 11:51 AM, Alessio Vanni wrote:
> The GNUNET_OS_ProjectData struct contains two fields, `config_file' and
> `user_config_file'.  By default they are set to "gnunet.conf" and
> "~/.config/gnunet.conf".
> 
> When these fields are set to a different name, the application refuses
> to start.  It seems the problem is caused by the fact that the
> application is unable to find the required informations to connect with
> GNUnet, i.e. the specified file must be a copy of gnunet.conf instead of
> containing only the application-specific configuration for the
> application to work.
> 
> 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