On Wed, Feb 3, 2021 at 3:07 PM Tobias Vogel <tobias.vogel(a)linux.com> wrote:
thanks for your detailed reply and my appologies for not being more clear
about my use case!
The extension will let the user compile a list of remote hosts that i
currently store in a SQlite DB. Now the location of the ".db"-file is what
I need to store somewhere on the Server side.
I assume this "list of remote hosts" is not the same list of hosts on which
you use cockpit. When you need to store some database on the server just
pick a well defined location and use that. (like
Has the cockpit API maybe an easy way to retrieve the directory where an
extension lives in?
I am not aware of it, but it would not be hard to write a simple function
to find from where the extension is being served. But I would argue for not
using that for storing any arbitrary data mainly as users may
remove/reinstall your extension and the data would go with it. Also
cockpit has a hierarchy of locations so it may happen that you would start
using another location thus the data would not be found.
Alternatively I thought about storing the database elsewhere (like a
MySQL-, Postgres- or other relational DB) - however, this would require the
ability to enter the db connection-details and again store them somewhere
on the Server side.
Am 3. Feb. 2021, um 07:28, Matej Marusak <mmarusak(a)redhat.com> schrieb:
> Hey Tobias,
> You haven't said exactly what it is that you are trying to store. For
> different data, there are different approaches. I can think of a couple of
> different cases:
> 1. I'll start with stating the main idea behind cockpit - it is just UI
> around other tooling, so ideally that other tooling would deal with it and
> cockpit would just read/manage it. Such example is for example how we would
> "store" user preferences for kernel dumps. We read the current settings
> from /etc/kdump.conf and show that on the page. When a user selects
> different options, we just tell kdump what the user wants and it updates
> this config (or we might edit that config directly, not sure now). Cockpit
> in this case is really just an intermediator.
> 2. You want to store something about how the user uses the UI itself.
> This is for example how you would select the language or color of
> 'Terminal'. This is saved in Cookies (for example look for `theme_cookie`
> in the source code to see how it is being used). There are other browser
> storages available that you can use. They all differ for how long the
> settings are saved. What they have in common though is that they all are
> only for you current browser and if you connect to the same machine from
> somewhere else or with a different browser, you will lose these settings.
> 3. There are cockpit configuration files. These are not really what you
> want for your extension, so moving swiftly on, but you can read about it in
> 4. If you still haven't found what you need you are left to designing
> your own storage. The same way how you would create some config for your
> command line tool, you can create such config for your cockpit extension.
> About where on the system the file should be located is very dependent on
> what you are trying to achieve and SO can always be helpful with that :) 
> Hope this was to some use.
> Happy Hacking,
>  https://cockpit-project.org/guide/latest/cockpit.conf.5.html
> On Tue, Feb 2, 2021 at 7:38 PM Tobias Vogel <tobias.vogel(a)linux.com>
>> I am working on a Cockpit-extension and was wondering what the
>> proper/preferred way is to store data from the user (variables,
>> preferences, etc.)?
>> I couldn't find any information regarding this in the documentation.
>> Tobias Vogel
>> cockpit-devel mailing list -- cockpit-devel(a)lists.fedorahosted.org
>> To unsubscribe send an email to
>> Fedora Code of Conduct:
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
cockpit-devel mailing list -- cockpit-devel(a)lists.fedorahosted.org
To unsubscribe send an email to cockpit-devel-leave(a)lists.fedorahosted.org
Fedora Code of Conduct:
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
Senior Software Engineer