@alefattorini could you kindly edit the first post to a wiki post?
EDIT: Thank you, now i can update the content
Hi Martin, sure I am.
Glad to see that there really is any interest in Vaultwarden as NS8-module going further.
I’ve managed to recover my broken VM I’ve used last year and pushed some minor changes I do not understand myself anymore to my GitHub repository.
Edit: Workflow is broken, too. That was not my intention
As I’m neither a programmer nor had anything else than the ns8-kickstart I had quite a hard time to get to where I’ve left off last year. Thus it might be better to take your work as the base rather than my try - feel free to have a look.
Kind regards
Christoph
Update your yarn lock file, its out of date thats why.
could someone help me figure out why i am getting the following error here
2024-03-08T23:29:05+03:00 [1:2fauth2:systemd] 2fauth-app.service: Ignoring invalid environment assignment '2FAUTH_IMAGE=docker.io/2fauth/2fauth:5.0.4': /home/2fauth2/.config/state/environment
2024-03-08T23:29:05+03:00 [1:2fauth2:systemd] 2fauth.service: Ignoring invalid environment assignment '2FAUTH_IMAGE=docker.io/2fauth/2fauth:5.0.4': /home/2fauth2/.config/state/environment
2024-03-08T23:29:05+03:00 [1:2fauth2:systemd] Stopping Podman 2fauth.service...
2024-03-08T23:29:05+03:00 [1:2fauth2:systemd] 2fauth.service: Ignoring invalid environment assignment '2FAUTH_IMAGE=docker.io/2fauth/2fauth:5.0.4': /home/2fauth2/.config/state/environment
In relation to this App geniusdynamics/ns8-2fa: NS8 App for 2FAuth https://docs.2fauth.app/ (github.com)
is it that its not permisible to have something like this
Is 2FAUTH_IMAGE an environment variable?
If so, systemd.exec manual says this:
The names of the variables can contain ASCII letters, digits, and the underscore character. Variable names cannot be empty or start with a digit. In variable values, most characters are allowed, but non-printable characters are currently rejected.
Note that environment variables are not suitable for passing secrets (such as passwords, key material, …) to service processes. Environment variables set for a unit are exposed to unprivileged clients via D-Bus IPC, and generally not understood as being data that requires protection. Moreover, environment variables are propagated down the process tree, including across security boundaries (such as setuid/setgid executables), and hence might leak to processes that should not have access to the secret data. Use
LoadCredential=,LoadCredentialEncrypted=orSetCredentialEncrypted=(see below) to pass data to unit processes securely.
As I’m clueless when it comes to podman, docker, containers et all, and there seems to be general environment variables as well as podman environment variables restricted to each container, take it as a grain of salt.
Unrelated to your question but related to Better Secrets Management for NS8 Apps - #5 by Tbaile, regarding handling of passwords/secrets without using podman --secret, I think the code with --env refers to podman environment vars (so scope is constrained to container, but defined in a systemd file). But if devs have already taken these things into account and it is a widely accepted and spread method, I’m surely non the wiser.
in relation to VAultwarden,
How do i fix the error File "/home/vaultwarden3/.config/actions/create-module/20configure", line 12, in <module>
import pyargon2
ModuleNotFoundError: No module named 'pyargon2'
in the context of NEthserver 8 App?
Authentik Abov is Ready for testing here: Authentik-SSO App for Nethserver 8 - #3 by oneitonitram
2 Likes
Maybe too late: For me it looks like pyargon2 isn’t installed at OS level by default. My personal opinion would be to install that via system package management and try again - however that will only work pre-install.
Might the following be an option
- inside create-module get a random string to use and save it to a file inside module home (e.g. GitHub: chrkli/ns8-vaultwarden - actions/create-module/02create_secrets
- Pull vaultwarden container as normal
- Inside systemd unit use ExecStartPre to exec
vaultwarden hashwith input from file generated in step 2 and pass its output directly to ENV of starting container
Pros:
- Possibility to display the current secret within the UI
- User may customise the admin-token from within the UI
Cons:
- Startup time for container might increase as there has to be done more
- Startup will fail completely is ExecStartPre fails. It’s possible to tell systemd to ignore ExecStarPre failure, however in this case vaultwarden-admin will not be available due to missing token inside ENV
Okay I’ve should have read the manual completely before making suggestions:
Some lines below is an explanation on how to achieve the secure token generation with default linux tools available:
GitHub: dani-garcia/vaultwarden - Wiki/Enabling-admin-page#using-argon2
Thank you for your work until now!
I would love to see Matrix Synapse as a messaging and collaboration server for a emergency communications (EMMCOM) Project I am working on…
Is there a time schedule for a matrix-module?
1 Like
I am glad you see value in the works I am doing, thank you for your kind words.
As stated above on the app, not sure where to begin.
Matrix synapse alone is fairly or probably easy to implement, however alone, it’s baseline useless and you’d rather just use the builtin mattermost.
Matrix has way too many moving parts, options are implementing each separately and individually, similar to what most other systems like Yunohost are doing, however, from NS 8 app dev experience.
Its extremely cumbersome and complex to have different NS8 apps to play well together.
I am still working on figuring out how this could be achieved, and I would be happy for any member of the @app_authors to chime in and help brainstorm on ideas for achieving this.
I would love for it to be available yesterday, however I am still building experience in more complex topics and scenarios,
Also, whichever direction I chose to use as a starter , the initial version, unless it stays in dev-testing tag for a while, I would need to make consideration for future updates and upgrades, in the way I believe a matrix server should be implemented.
I don’t have any time frame as of yet, unless someone from the @dev_team would spare some time to brainstorm on many questions I have in relation to potential methods for achieving this.
I would like the matrix implementation in Nethserver 8 to be robust, yet provide abit of option and customizability. Similar to the matrix ansible playbook.
I would. Like bridges to work, etc.
2 Likes
@chrkli i attempted to install pyargon2 on my os base, but with no success, pip install pyargon2 failed unless I am missing something.
You should note as well, plain text secrets are no longer allowed by vaultwaden. Used to be possible. The pyargon2 generated secret is not what the user is going to be using, it’s what vaultwaden needs to know, however the user needs to have their secret that vaultwaden will decode. So other methods become useless. I had tried others before.
The only other option left is now is using the builtin generator, as seen on the repo to generate secret, and using interactive method, retrieve what vaultwaden has generated and store it as env.
While I think this might work. I think i broke my services with the many edits, so they are no longer working, and the generation can only work if the app service is running already.
Ussually before an app is working I do not branch out till it works… Still alot to figure out.
@oneitonitram You are absolutely right with that, and I’m aware of that fact, too. But I’ve never intended to pass the generated plain text password to vaultwarden.
My intention was to use OS-provided argon2 cli tool (not within python itself) to create the needed hashed version of the admin-token generated during create-module. If that fails (e.g. argon2 command missing from system), run vaultwarden hash to hash plaintext-token correctly.
I’ve done some bash scripts for exactly this purpose, please see following commit within my own repository.
Also, thank you for your tip that i need to update the yarn.lock file. I’ve now synced quite a lot other files with ns8-kickstart template, now the github workflow ran fine 
1 Like
will authentik be able to read the argon 2 and translate it accordingly?
Hold it, I’m not saying that launching secrets in environment space is the best course of action (although some applications want it this way and only this way).
The documentation above states that writing secrets DIRECTLY IN TO THE SYSTEMD file is insecure, which is defining an --environment with a hardcoded password.
You can safely pass an --env-file or a --secret to the podman command and call it a day, since it won’t be exposing anything to systemd.
Back to my post, what I am against is a centralized secret handling system, which is a bit overkill for the usage and only useful in case of secret rotation and/or load balancing between systems.
Podman already has a secret handling system (which is basically writing it into env or a file, so back to square one)
2 Likes
I beg to disagree with you on the fact that it’s overkill. Quite to the contrary.
I relation to better secrets management topic
My bone of contention was in relation to these credentials arr exposed on the code of all Nethserver apps github pages.
Wouldn’t it be better to just have a defined {nethSecrets.environmentName} for all defined credential secrets on Nethserver apps.
Then using automatically generated secrets, these are passed to the app.
While it’s already possible to auto-generate etc,
The user, for cases like database login for some apps, the user is still required to be aware of what the said secret is.
In relation to load balancing and secrets rotation, the more reason why it would be necessary. Especially the load balancing bit.
As with regards to secrets rotation, now that’s the overkill part.
We’re going a bit farther from the subject than I’d like.
The variable name is, in fact, published to the repo, you can masquerade it, but it doesn’t make a difference. If the container is hacked in any way, no matter what name you give it, the complexity of the key or whatever, it’s gonna get stolen.
If you want the user to be aware of the password, there’s no need for this anyway, you can generate it, save it somewhere, then show somewhere (the UI, for example, the password field is already provided by the core, you can set it as readonly)
Having a full rotation/management of secrets for less than 50+ entries is just expensive and it’s gonna add complexity to the software. (Handling credentials is not the scope here)
I’m smelling that the issue faced here resides more on the applicative side of the software than in the “orchestrator” side
Any examples? Just to get a fuller picture of the request
We could be, in context of secrets for this topic, so might be welll to have them discussed in the better secrets management topic.
NOW
Nethserver is now a platform, and in context, once a product becomes a platform, and in relation to the concepts applied with it, its going to get way too many users to the platform.
In this case, the developers have no control whatsoever, what the users are going to build and what they are going to host on the said platform. PERIOD.
Now relating to the same, this wonderful platform, now has multi node and cluster support,{ (NOT)many orchestration and hosting platforms have these}
A user might host 50 wordpress sites within the general Nethserver cluster.
An IT company, if the platfrom comes to support most of the tools IT and Software Dev companies USe, might choose to host all their infrastructure tools with Nethserver, and on average, a Software dev company uses about 15 tools for operations.
with these use cases in mind, and since we hope Nethserver grows, and we currently understand the forthcoming challenge, and since its within our power to support it, wouldnt it be wise and in order to support a structure where these tools and solutions, built for nethserver 8 are implemented following best practices both for internal and external purposes.
the tools are already freely available to get the job done…
You are correct somehow in this regards. every @app_authors can implement their application to automatically generate the credentials for their Apps databases and Hypothetically present the credentials in the User interface. (More work for the App Authors) Also, maintenance headache for the sys admins managing their infrastructure
At the moment, only afew apps present readonly passwords for database on the interface, the rest the user has to dig in to the docs, or get the env details from inside the apps.
Is it necessary, NO, would it be worthwhile in the long run YES
It would be a one time implementation headache for the core, but would be heaven for both app builders as well as sys admins managing their tools inside nethserver.
Does this give the picture you’re looking for?
kindly install the glpi App and set it up, as it is currently constituted, and while thats a unique case at the moment, its just the beginning.
And NOBODY will have to support this security headache!!!
I would not touch any app integrated by a half baked progranmmer with no idea of security!
And the questions and “reasons” given here are certainly NOT reassuring!
A few posts ago it was “I’m learning, that’s why so many questions.”.
Yet now, I see a beginner trying to out-argue an experienced programmer (two actually, including Stef) about security…
Very disturbing vibrations in the force here!
My 2 cents
Andy
1 Like