FreeIPA client's cache directory USER_CACHE_PATH is hard-coded to use XDG_CACHE_HOME or ~/.cache. It's correct path for users. However for services like custodia, a dot directory in the home directory is not well suited. Since the directory is resolved on import time, it is not easily to configure the cache directory in Python code.
USER_CACHE_PATH
XDG_CACHE_HOME
~/.cache
Proposal: Move the cache directory to ipalib.api.env and make it configurable.
ipalib.api.env
You can set XDG_CACHE_HOME to another location in your service unit.
Thanks, but I consider your proposal as a workaround, not a permanent solution. Also it changes the setting process-globally instead of API-locally,
Do you really need to set cache location per API instance instead of per process? I can't think of reason why you would want to do it. Could you please provide use case? The obvious reason not to do it is that then the schema will be fetched for every API even though it's identical.
What I meant to explain: the location for cache files of an IPA API object should be part of the API object configuration. It shouldn't be a process global that is defined on import time.
pros:
api.bootstrap()
api.env
~/.cache/ipa
cons:
Related to this issue, the cache directory is considered optional by all components that write to the cache directory. In case the location is not writeable, the problem is only logged but no error is propagated to the caller. This is more or less fine for users but problematic for services that rely on cached files for performance, e.g. KRA transport cert cache.
A service should fail early when it can't write to its variable data location.
Also related to the issue: let's get rid of ~/.ipa for logging or other stuff. All files should be in one directory tree and the caller should indicate the directory.
~/.ipa
@cheimes , could you document, e.g. in separate design doc, how exactly custodia wants to use IPA libraries? And what are all the conditions which are different the usual usages of those libs.
Later, it should be transformed into creation of integration test suite which will test the same usage (and not necessary need custodia).
Seems to me that from minor change it is creating a bigger snowball.
@pvoborni this is useful not just for custodia, but also for out own test suites and being able to run them in a more agile way. I highly approve of removing hardcoded paths like these, they just do not belong in a library, they should be configured by the program using the library (and hopefully exposed as options to the user when it makes sense (for example test suites).
@simo maybe, that's not the point. I'm more general here.
The usage needs to be documented. We will then avoid needless discussions.
And if anything is needed for anything else then the problem needs to be specified as well. And it should be solved when it becomes relevant.
Metadata Update from @pvoborni: - Issue set to the milestone: FreeIPA 4.7 - Issue tagged with: rfe
Triage comment: - once #6408 is fixed (4.6), ~/.cache/ipa will be used only for the CLI
So this might be closed as won't fix in the end. Because there will be no use case for it.
The issue #6408 and this issue are not related. #6408 is for the case I don't want to talk to a remote server. This issue is about the case when I want to talk to a remote server from a service.
For service case I want to have a schema cache. But I must to be able to specify the location of temporary files, log files and caches.
Metadata Update from @cheimes: - Issue set to the milestone: None (was: FreeIPA 4.7)
Why do you want schema cache?
Cache is needed now to download metadata. Metadata are needed for CLI to know which commands exists and e.g. what to offer to CLI users in help or to do client side validation.
But services are not interactive. You code-in the API usage, therefore you don't to discover anything which also means you don't need metadata and therefore you don't need cache. Assuming that #6408 goal is: https://pagure.io/freeipa/issue/6408#comment-433307
Forget about #6408. The issue is for Ansible integration, not for Custodia Vault integration.
I don't care about the schema. I just want to call API functions. How do I stop the ipaclient package from requiring a schema download? As far as I understand ipaclient and ipalib, it always downloads the schema if ipaserver is not installed.
The cache directory is used for more than the schema cache. It's also used to cache the KRA transport cert.
So what about this: #6814 ? Maybe it is still missing some acceptance criteria.
Metadata Update from @pvoborni: - Issue set to the milestone: FreeIPA 4.7
The issue is causing bugs in Custodia, e.g.
May 10 12:08:47 vm-058-173.ipa.example systemd[1]: Starting Custodia Secrets Service for ipa... May 10 12:08:48 vm-058-173.ipa.example custodia[48203]: 2017-05-10 12:08:48 - custodia - Custodia debug logger enabled May 10 12:08:48 vm-058-173.ipa.example custodia[48203]: 2017-05-10 12:08:48 - custodia - Custodia audit log: /var/log/custodia/ipa/audit.log May 10 12:08:48 vm-058-173.ipa.example custodia[48203]: 2017-05-10 12:08:48 - custodia - Custodia instance ipa May 10 12:08:48 vm-058-173.ipa.example custodia[48203]: 2017-05-10 12:08:48 - custodia - Config file(s) ['/etc/custodia/ipa.conf'] loaded May 10 12:08:48 vm-058-173.ipa.example custodia[48203]: 2017-05-10 12:08:48 - IPAInterface-[auth:ipa] - Kerberos principal 'custodia/vm-058-173.ipa.example@DOM-058-173.IPA.EXAMPLE' May 10 12:08:48 vm-058-173.ipa.example custodia[48203]: ipa: WARNING: Failed to write schema: [Errno 13] Permission denied: '/.cache' May 10 12:08:48 vm-058-173.ipa.example custodia[48203]: ipa: WARNING: Failed to write server info: [Errno 13] Permission denied: '/.cache' May 10 12:08:48 vm-058-173.ipa.example custodia[48203]: 2017-05-10 12:08:48 - IPAInterface-[auth:ipa] - IPA server 'vm-058-173.ipa.example': IPA server version 4.5.0. API version 2.224 May 10 12:08:49 vm-058-173.ipa.example custodia[48203]: ipa: WARNING: Failed to save /.cache/ipa/kra-transport-certs/dom-058-173.ipa.example.pem May 10 12:08:49 vm-058-173.ipa.example custodia[48203]: Traceback (most recent call last): May 10 12:08:49 vm-058-173.ipa.example custodia[48203]: File "/usr/lib/python2.7/site-packages/ipaclient/plugins/vault.py", line 573, in store_cert May 10 12:08:49 vm-058-173.ipa.example custodia[48203]: os.makedirs(self._dirname) May 10 12:08:49 vm-058-173.ipa.example custodia[48203]: File "/usr/lib64/python2.7/os.py", line 150, in makedirs May 10 12:08:49 vm-058-173.ipa.example custodia[48203]: makedirs(head, mode) May 10 12:08:49 vm-058-173.ipa.example custodia[48203]: File "/usr/lib64/python2.7/os.py", line 150, in makedirs May 10 12:08:49 vm-058-173.ipa.example custodia[48203]: makedirs(head, mode) May 10 12:08:49 vm-058-173.ipa.example custodia[48203]: File "/usr/lib64/python2.7/os.py", line 157, in makedirs May 10 12:08:49 vm-058-173.ipa.example custodia[48203]: mkdir(name, mode) May 10 12:08:49 vm-058-173.ipa.example custodia[48203]: OSError: [Errno 13] Permission denied: '/.cache' May 10 12:08:49 vm-058-173.ipa.example custodia[48203]: 2017-05-10 12:08:49 - IPAVault-[store:vault] - KRA server(s) May 10 12:08:49 vm-058-173.ipa.example custodia[48203]: 2017-05-10 12:08:49 - IPAVault-[store:vault] - Setting vault type to 'service' from Kerberos May 10 12:08:49 vm-058-173.ipa.example custodia[48203]: 2017-05-10 12:08:49 - IPAVault-[store:vault] - Setting principal 'custodia/vm-058-173.ipa.example' from Kerberos May 10 12:08:49 vm-058-173.ipa.example custodia[48203]: 2017-05-10 12:08:49 - server - Serving on Unix socket /var/run/custodia/ipa.sock May 10 12:08:49 vm-058-173.ipa.example custodia[48203]: 2017-05-10 12:08:49 - server - Using systemd socket activation on path /var/run/custodia/ipa.sock
I cannot set XDG_CACHE_HOME in the service unit because the path to ephemeral runtime data is a config option in custodia.conf. But I can neither change XDG_CACHE_HOME or HOME after the config is loaded. IPA defines USER_CACHE_PATH at import time of the module. By the time Custodia has loaded and parsed the config file, IPA has already set USER_CACHE_PATH.
HOME
Metadata Update from @cheimes: - Issue tagged with: integration
Metadata Update from @rcritten: - Issue set to the milestone: FreeIPA 4.7.1 (was: FreeIPA 4.7)
FreeIPA 4.7 has been released, moving to FreeIPA 4.7.1 milestone
master:
ipa-4-9:
Log in to comment on this ticket.