Also on the Same Note, i think it would be great, especially for new users and for marketing perspective to have a page like this originating from the main NS8 homepage
When someone visits the new NS8 website, they will also get a link for available software or tools. or even a software marketplace. which will have the page that lists all the programs that Ship with NS8 by Default, all and categorised, as well as those that are community built.
that way, someone doe snot need to install a server, but can get a picture and understanding of what’s possible already, and tools already available for installation, before they even think of installing something else.
Also, if there was an option to name the instances, and have the named name available instead of the generic, nextcloud 1 etc for the deployed application, would make the interface alot more better.
Ability to name Application instances from the application setting name, is a welcome.
KIndly have this name changed to Manage App instead of Open App, because open app would mean, accessing the application intself, but in this case, we are acessing it to manage it features and functions
Modules published are not related or source is not mentioned. Are there plans for labeling modules e.g. “Official modules” and “Community modules”? And how can one be assured of a “100% safe” Community module?
IMVHO “100% safe” is a wrong assumption from start.
developer managing the module and Nethesis can’t make any kind of assement or security statement in spite of the module software
any software might contain a security issue still not discovered
anyway, when the module software receives an update, the module mantainer might not have time/resources/whatever to provide the updated version in a “glad” timing for the users
last but not list when NS8 will be released as a product (subscription available) i don’t think that Nethesis will provide support for all the configurations, unless a specific list of cases/rules
Without forgetting that… A safer NS8 cluster have no unnecessary software/module installed. The safest is the… powered off one.
Agree, but at least an attempt (without false positives) is a step. Just like Apple and Google try with their app stores.
Doing nothing is a worst case scenario IMHO. And NS has to protect trusted modules and untrusted modules. A ‘do whatever you want’ scenario is a complete no go IMHO.
Actually I think it’s the current goal.
No module will appear in “module list” without at least some verification of “nothin really wrong” with the candidate.
However, no one is avoiding any developer to create any module from any docker/podman container and install it into personal NS8 cluster. Why any GPL project should act against personal initiative?
Double achievement:
no developers time used for the specific container adaptation to NS8 structure
information about possible adoption of this module and… sort of “market test” on how this is so much interesting for the community.
I mean…
Mattermost arrived "for free on NethServer… assuming that Nethesis needed a Slack alternative, so they adapted, tested and… released. Maybe not Nethesis, maybe a customer. Who knows.
On “NS end user side” (which is the sysadmin, not a Clueless User): maybe lesser of peace of mind (sort of)
On “hands up user side”: wiggle room to use the preferred container into NethServer and not into another separate system (assuming there could be a will).
One marvellous thing about NethServer: you can setup a fully fledged test server for more than 180 days!
That is exactly what I am looking for, but 'a more robust ‘some verification’ and by who.
I have always very much appreciated, and still am, of the devs from Nethesis and @stephdl and @mrmarkuz for the many modules, and I see their work as ‘developed by trusted community members’. So I was looking for how NS8 modules are going to be qualified/labeled.
Actually, BEing that i hav published a Module on the NEthforge repo, and thos modules appear on the software center, i have noted that the develoeprs of nethserver do actually take their time to deploy, test and review the application, and if they find any challenges or issues,
the developer is notified to recify on that before they are published.
so, Due diligence is taken for modules on the nethforge repo, unles a module was developed and not released to the nethforge repo.
Personal opinion mode on
Currently deliver/assess more modules is “nice” but not a top priority for devs, both projects need to be “released” as first task.
Personally I don’t feel there will be some sort of “process documented and reported”, mostly because module number won’t be “so big”. Tenths, one hundred top => document, governance and status report seems quite an overkill.
Moreover… I’d hardly believe there will be more than one module submission par month, once NS8 will be delivered as day to day setup.
you can expect all processes being used are documented now, even before the Release is out, do you?
i agree
for module number, that depends on the scope of the project managers,
if they want Nethserver to be the defactor way Self hosted applications are installed on Linux Server, that wont Hinder there being thousands of Applications.
then the process would be,
SOmeone goes to Digital ocean, deployes Nethserver, configures it, then Deploys Software A,B,C,D
ofcourse i am not talking about the hard cores, that use Ansible and terraform and kubernetes cluster nodes, etc for their project, those are on a league of their own.
I am mearly taking about small enterprises that need an Invoicing tool like Invoice Ninja, and a password manager, like Authy/Vaultwarden etc.
Custom repo: option to allow anyone to add a personal/custom repo not governed by NethServer/Nethesis. Some use cases: module dev testing, internal software (for instance with license restrictions preventing to be shared with the community), pay-wall modules, personal repo or cloned repos to have full control even if NethServer repo(s) are down (possible problems with updates from official and cloned repos?).
If NethForge is a github repo controlled by NethServer devs, everything pushed there could be evaluated almost in the same way it is done on official repo (build automation, unit tests -but coded by the module mantainers-, generic security audits like some of the ones built-in/endorsed by github to check if the code is using old/vulnerable dependencies and alike)
