I split this service into another module or not?

I would propose this, if it makes sense.
For useable systems, like the normal modules we have, let’s call them Apps

For the kind of apps that are generally not useable independently, and require other components, for. Embeddings, let us call them Services or any other word that would have a better meaning scope.

I have noticed something concerning while looking into the modules built and the ones we are building. Some and most of them, do require some integrations that could be achieved by other solutions, or systems, but these are implemented inside a given module or app.

If that given component is 300MB. And 5 different modules make use of the same, we are making the modules heavy for nothing.

We could have implemented a single “app” in this case a “service” that is installed independently, and all other apps that require or depend on it for their Functionality just use it as a reference.

What do you think about this @davidep

I understand it, let’s split the topic before going off-topic!

When you are planning an app architecture you often have this question: should I split this service into another module or not?

In the end I often prefer the “heavy way” because it is easier from both development and administration point of view; it’s more flexible than creating “generic apps” (e.g. MariaDB app). With “generic apps”:

  1. the components lifecycle is unpredictable. If some app wants today MariaDB X, tomorrow may want MariaDB Y: how to make it work with all the possible client apps?

  2. simple deployment, development and maintenance: a centralized MariaDB instance serving multiple client apps is more difficult to backup, restore, move etc. and is a single point of failure.

I understand your point, and that’s the main architecture used, in this case I am talking about internal components that may or may not be required. Eg nextcloud right now does not have coturn, but is required for calls to work, we could add coturn into nextcloud or just implement coturn as a separate app.

Similarly nextcloud signaling in the form of HPB for talk

There are multiple other apps as well that depend on coturn. So for this case would it not be best to build coturn alone, then have the module that depend on it integrate into it.

Equally multiple instances of Nethserver can use it.

This is just but one example.

And also here, Nextcloud could demand version x.y.z of Coturn, yet another application may require version x.y.y…

This is just but one example…

My 2 pieces of glowing coal…

(Acting Avocat Diabolis)

I understood that point the first time @davidep pointed out. As with the example given, these kind of solutions to be used most are version agnostic.

Similarly, it does not prevent pushing more than one version of the same.

If 4 instances of nextcloud need version x
2 instances of matrix homeserver need version Y.

We could have one instance of version x for all the 4 instances of nextcloud.

One instance of version y for the 2 matrix instances.

With this regards, we are only using 2 instances. Compared to 6 instances of the same.

With option 1 above, if one instance is 300mb we only need 600mb

With option 2 we need 1.8gig of storage.

@Andy_Wismer you’d be assuming the module developer is not keeping up with what depends on what, which is wrong.

If we made do in NS7 haxky ways of making newer versions of some dependencies because epel, couldn’t we do a better job with NS8.

It would very hard to call this kind of environment SME…

On the other hand, if you want enterprise style, what is 1.8 gig? Peanuts!

I’ve seen recently plenty of examples, here in the forum among other places… :slight_smile:

I really do not think NS8 needs enterprise style planning. Before any of that, a form of redundant Account Provider has to be available, for starters. Two LDAPs or two ADs, each running on a different “Node” and / or hardware, ready to automatically take over, when needed. As MS does with AD, or others do with LDAP.

The closest NethServer has come to an “enterprise” like environment in the past was with the Hot-Spare server.

My 2 cents

It seems you’ve not really been testing NS8 well. This feature and functionality is actually already available in NS8. You can deploy a single ldap instances, with multiple deployments in more than one node or even the same node.

The reason for my concern is actually for SME. Enterprise has not worry for storage, SME on the other hand does.

With a few NS8 modules, 50 gigs storage is not enough for NS8, but NS7 it’s more than enough for myriads of modules.

I don’t understand why suggestions I make are deemed “enterprise” by you @Andy_Wismer

I don’t test LDAP in NethServer, as LDAP doesn’t allow for authenticated shares, which any SME company needs.
And AD is only allowed once so far.

I only use AD, as only that offers secured shares.

LDAP, in NethServer doesn’t allow for authenticated shares, so is basically not usable for any of my clients.
And as SME companies have no need for several Account databeses (At least mine are glad for a single AD), I don’t see any need for this.

A lot of suggestions seem last last ditch resorts to finally be able to update your NS7, but as that is dependant on a badly planned placement of a server (NS AD in the cloud), you still seem stuck with that specific environment.

You also tend to bring examples like “4 Nextcloud” and “2 Matrix” instances. A real SME wants all employees using the same tools, not duplicating efforts.

It would be so easy, even with AD in the cloud (your specific predicament), but if you don’t have the vision to picture a solution, and don’t listen to davice, when given how to easily solve your issue (Without incurring great expenses!). I can’t really help.

Your last posts concerning that server didn’t find much responce, neither diid your claim your AD planning is “common” here…

My 2 cents

Why not, yes I’d like it. It could be a long-term goal for NS9! What we implemented for the LDAP database can work also with SQL engines: modules will discover available instances of MariaDB or PostgreSQL in the cluster, obtain credentials and use it. This will reduce the number of database instances in big nodes.

For now NS8 core provides a centralized management for

  • HTTP routes and TLS certificates
  • Node Firewall ports
  • LDAP database (with multi-master replica)
  • SMTP settings to send notifications
  • Backup repositories and schedule
  • Software updates
  • Log collection and viewing

All those aspects need improvements (and probably fixes…) in the near future. But for longer-term plans we can extend the core features! However, before making the dream true, we must learn from real use cases.

1 Like

i think @Andy_Wismer requires AD for this one,as Ldap is not SME enough

So long as it works, and works well, its probably fine.

While building modules and for some modules planned to be built, i noticed this kind of interdependence.

I will in the future implement some components for modules that would and can be reused by multiple other modules, that way it makes alot more sense.

The best example is this one discussed here Ejabberd on NS8 and Nextcloud Improvements - Feature - NethServer Community

Nextcloud needs High Performance backend server, while it can be integrated into nextcloud, i have discovered it doesnt make sense, as a single HPB instance can be used by multiple nextcloud instances, either on the same node or more within the cluster, Potently even outside the cluster.

SO a separate module that implements only that makes alot more sense.

Is there a new High End Backup Server?
I’ve heard of High Performance Backends, but so far not about a High End Backup Server…

LDAP may be fine for “Cloud” environments, but as far as SME uses Desktops, a Share access is a must. LDAP as such is not of ANY use for a typical SME, which does not want two account providers (databases). And since LDAP doesn’t work for authenticated Shares, why would anyone want a separate database eg just for Mail?

If it comes for NS9, fine. Even for NS8.1 or NS 8.2.
But as most other Linux can handle a multi master AD, NethServer should also be able to do so, even a mixed AD Windows / Linux should be - more or less - possible.

If NethServer moves to a pure Cloud environment, it is of no more use for me or my clients. Too bad.
But as said, I can do my own solution, NS7 was nice as it went, bumpy in the beginning, but better and better - at least until RedHat pulled the plug on Centos8 RHEL…

RedHat has, in the past, made a lot of “stupid” pushes, like pushing BTRfs, then dropping it like a hot cake, same with eg. XEN. Come to think of it, RH hasn’t brought much to the table for the Linux Community in general. They bought a lot of other, innovative companies, but YUM, or the old YelloDog Update Manager was not a RH idea or creation for one. SSH? Comes from OpenBSD Theo deRaad.
Apache & Samba? A. Tridgell…

My 2 cents

THis is being too rigid, which is not great in IT,

I believe you have read the announcement fo NS8, and hurrey as youve been waiting for, NS8 is finally released.

NS8 is meant for Hybrid clouds, where the organization works with both Cloud and Onprem deployments. you are not an advocate for and do not love cloud, its fine, but not all organizations especially SME have the resources to maintain their own severs, so they will continue to use AWS, Azure, Digital ocean and the likes. and might have a small compute in the office acting as a server.

NS8 is finally released, but still a lot is missing. Mostly Third party modules, like Zabbix from @mrmarkuz, Dolibarr and DokuWiki from @stephdl which still needs testing for Migration…

IT is, as such, a tool for most of humanity. For me and others, it may be a hobby. For the majority, it is merely a tool. A Tool which serves no purpose just costs money and wastes resources, even if it’s just space in your toolkit.

Some things in IT are highly overvalued, at least in my opinion. KI is one, Advertising is another. Worse are “Crypto”, and these have nothing to do with encryption, as the name may imply.

I have three doctors practices as clients. These are typical, down to earth, small companies, doing tangible work with patients. Swiss law doesn’t allow any patients data put in a cloud, it has to be in Switzerland. As none of the major players offer cloud in Switzerland, this restricts use to smaller, local outfits, with much less options or hardware choices. All this induces higher costs, and absolutely NO benefit what so ever for my clients…

None of my clients want to use any cloud, some even act allergically to any “cloud” suggestions.
This may be “typical swiss”, but things are, as they are.

I personally do not like services which are billed regularly, especially if these can be avoided.
And AWS, Azure, Digital Ocean are all such regular billers…

I find it really strange that these companies you mention have the funds for enriching such multi-mega companies, but do not have local services. On top of it, most of these are in countries with really crappy Internet connections (And otherwise sub-par infrastructure)…

I do know you love cloud a lot, maybe too much, but that’s not a decision for me to make or judge. Open Source does allow this.
Cloud had an organized push while the world locked down for Covid, but Home Office is being rolled back in so much places and large corporations…

Cloud companies like AWS, Azure, Digital ocean all treat their clients as a number in a clients database, a potential source for milking.

Hybrid cloud is, at the moment for me:
All in house, public Web page hosted externally. External Mail only a maybe. Nothing else.

You have your opinion, I have mine, let’s leave it at that.

My 2 cents

Dokuwiki is a core module, and is available already, Ldap support will be added in a future release.

Dolibarr Module is already implemented, Would need to work with @stephdl on the migration bit, since that has to be added into a core module of Nethserver.
Since its mariaDB, migration should be faily easy, AD is not yet implemented yet.

What version of Dolibarr are you using @Andy_Wismer

Ill Let @mrmarkuz work on Zammad and Zabbix, no work on zammad has been done from our end, and we do not intend to build the said modules, especially if @mrmarkuz is available to work on them. I would also love to have a Zammad module.

All in all, these are not the works from the Neth team, they have played their part in providing a wonderful platform, and my aim was to to have some nice modules available during launch, to push for better user adoption

you can buy extremely cheap hardware and extremely cheap internet in your country, its not possible in mine. $10 for you equals coffee, thats 20 cups of coffee in mine, oh, and with the current rate, maybe 30.

we all do what makes sense for all of us.

If you actually read what I posted, you can see that I said the modules aren’t usable so far as MIGRATION is missing or not working!

This is AFAIK valid at the moment for Zabbix, Dokuwiki and Dolibarr. (The last two AD versions).

I’m using AD for Dolibarr, what other version would I use? LDAP on NethServer is wasting a whole server!

Agreed, Switzerland is expensive, but:
a Nespresso at home is less than 1$. :slight_smile:

My 2 cents