Support for dotfiles

[blabut]

Hi,

I am new to Exegol and would love to get familiar with it enough to use it on my engagements.

One thing I'd like to know though: is there no way to add dotfiles to the container ? And if not, could this be a feature to consider ? I'd be happy to help implementing it. Here are two use cases I could think of:

• Adding generic stuff in custom dotfiles (aliases, program options...)
• I can't think of another way to persist gdb-peda in my conf, since it requires some configuration in .gdbinit file

Thanks anyways for such a great tool !

Cheers

[Dramelac]

Hi,

Indeed this is part of our next improvement point in our road map. This config issue (and not only) will be (probably) be part of "my-resources" functionality.

We are still thinking about the correct implementation for a better UX. If you have any suggestions, they are all welcome to complete our drafts.

Thanks for using Exegol and supporting the project !

[ShutdownRepo]

Here are some details on what we have in mind. The my-resources volume already exists in the ~/.exegol directory and is shared with exegol containers. In ThePorgs/Exegol-images@58f65a2, the my-resources/bin was added to the PATH, allowing users to load standalone binaries. We still need to work on that to make it fully functional but that's what we have planned for binaries.

Regarding aliases, it should be pretty easy to allow the user to load custom aliases through an .aliases file in the my-resources directory.

Regarding other dotfiles, like configs, it's hard to find a good implementation. So, like @Dramelac said, if there are any suggestions, please reach out 😄

[blabut]

Thanks to both of you for the fast replies !

I had a simple idea, but maybe is it too naive ?

How about copying files in an ~/.exegol/profile folder (name could be improved) to the /root directory of the container at startup ? This way, config / dotfiles file would automatically (I think) be read when opening a shell or a specific program (.vimrc, .gdbinit...). I would not be surprise if that would bring issues I did not think of, but I am curious to know :)

I understand that exegol aims at being quickly usable (which it's already great at). Could this be a viable customization option that would not be hassle for users not planing to use it ?

In order not to interfere with the preexisting .zshrc file in the container, a line could be hardcoded at the end of it to source a .zshrc-custom file that would as well be copied from the ~/.exegol/ folder of the host.

Happy to discuss this !

[Dramelac]

Thanks for the feedback and the effort!

To share with you our progress, your idea was part of the first track (with a version extended to all the filesystem tree not only /root).
However we want to keep some control 'by default' and not allow the user to overwrite a file that he is not supposed to customize because it could harm the evolution of the image (e.g. rewriting the alias file to add aliases would prevent our future updates from being applied in his environment).

We have so far retained another track, less generic and more complex but better controlled. Instead of targeting a folder (/root) we will support step by step the customization of some tools (such as vim, tmux, etc) because they have a limited number of config files specific to the user's personal experience. Other more technical tools can also be supported and we will encourage the community to help us to support more and more tools in this way.
This technique has the advantage of being controlled but does not leave much freedom to the advanced user who knows exactly what he is doing. We still want to give the user the possibility to modify his environment as he wishes and in any way possible and imaginable because this is also the philosophy of the project, easy, fast but automatable and that can be adapted to everyone.
To achieve this goal, we provide the user with an initialization script that will run at each container creation (with the my-resources feature enabled) to deploy a completely free installation and customization routine. This approach frees the user from any constraint to customize his environment, install plugins etc... We still encourage the user to use the first system to easily and quickly customize some tools and hope that it will evolve in the right direction.

We welcome any feedback and comments on our approach to identify potential problems, blockages or missing points!

Thank you!

[Dramelac]

The new system is currently in beta testing and will be available in the next release of Exegol.