Don’t forget, all user data must be downloadable by the user. All their data so email, files etc. in a ‘normal’ format like zip. This has to possible at any given moment by the user itsef. This is in a commercial hosted environment pretty important.
This is not the “traditional” NethServer deployment. Gabriel might record our discussions about “multi-tenant” features
…designed for small offices and medium enterprises
Will it change in the future? /cc @alefattorini
Good catch. Over here even residential internet connections have 120mbit bandwidth, companies even more. LibertyGlobal is now testing 5Gigabit down and 1Gbit up on those same connections. General roll-out expected next year.
So ‘my’ commercial market is moving away from ‘on premises’ deployments and trust a private cloud. Hence my focus on this.
Of course I remember discussions about “multi-tenant” features. Every day! I still use Zentyal for this (missing) feature!
But is not about that.
Why NS cannot be used for hosting an email server, web server, cloud services, on-line backup, and maybe other services, for a customer? Is not good enough?!? I doubt! I’m using NS for this kind of deployment.
I have two scenarios for NethServer in business environment for this deployment:
- One NS for each customer (email server, web server, cloud). NS could be VM or bare metal server.
- a. One NS for hosting email servers for all customers (unfortunately …)
b. One NS for hosting web servers for all customers (one web server/customer, using virtual host, but all on a single machine)
c. One NS for hosting cloud for all customers (one cloud server/customer, using virtual host, but all on a single machine)
Of course, a., b., c., could be VM or bare metal servers.
I think the future is now! Of course, not for multi-tenant email server feature!
I don’t know. Currently this is our market.
Good to know. Maybe you’re right
I don’t know how many Nethserver are used for this but I guess a small percentile.
When it comes to NethServer modules like: mattermost, nextcloud or others… probably we have different numbers
Okay, but I do not see any impediment to do that.
I think all home utilizations of NS use this kind of deployment: one server for at least email, website, Nextcloud.
Maybe is confusion because I used the plural (servers instead server).
5 posts were split to a new topic: Make a map on how and where NS is being used
Turned this in my mind since few days, and I faced always to go back at the beginning of my thought… do nothing rather to make a complex and probably broken code.
I do not love that but in this case I would like to fix the issue by a documentation chapter.
- State on the data is erased when you delete the user (actual behavior)
- You want to keep the data for any reason you need, then deactivate the user.
What do you think ?
I fully agree with you and Giacomo, however …
This does not work with remote account providers. I don’t like this limitation.
As Mark said above, we shall-not orphan user-data. To avoid that, a user can never be deleted! Instead we have to find a way to just mark it “deleted”. Putting it in “disabled” state is a kind of “soft-deletion” and everybody accepts it as a partial solution.
If we find a way to mark the user record as “deleted”, also saving the deletion time, we can implement a complete solution with timed data retention.
I return to my mind roundabout…
- ask to the remote authentication with the script
- store the result somewhere
- compare one day later with the new result
- do a diff
- With the diff set user as no longer in the AD/LDAP
- either ask to a manual action of the sysadmin
- or remove/move the data after Xdays
I propose to not change current behavior: keep all user data after delete
Then, implement a semi-automatic solution:
- create a new
- every package can add an action to delete its own data related to a user
- only upon request, the administrator can execute
signal-event user-cleanup myuser
No need to add “expiration” tags, synchronizing jobs or stuff like that.
All data remains there until someone explicitly delete them.
Do you want to change the current
user-delete semantic for local account providers?
If we add a new “cleanup” event some actions from user-delete should be moved from “user-delete” to it.
Yes, the delete shouldn’t remove any data. Honestly I thought it was already like this
Someone like a bot
This is really nice: a “soft-delete” implementation. We could make some tests with it!
Furthermore, both AD and RFC2307 define the “account expire” date: after that point the account cannot be used any more.
From that we calculate the expired account state. By defining a costant grace period we know when it’s time to take action. The action could be either
- erase user’s data (event
- send a notification of expired accounts
The grace period may vary from 0 to “forever”, if that makes sense (=action never occurs)
The account provider configuration UI should provide a method to configure the above properties for both local and remote account providers.
[Note] We already detect the password expired state, which refers to the Password policy. Do not confuse the user’s Account with its Password.
New database key proposal
data-cleanup=configuration AsyncRemoval=disabled GracePeriod=0 Action=erase
- AsyncRemoval enabled|disabled: if disabled the data is removed immediately (works only with a local accounts provider): this is the 7.5 legacy behavior
- GracePeriod when an account is expired wait for the given time before taking action
Action notify|erase: decide what to do with expired user’s data after GracePeriod has elapsed. Just notify (with email?) or
The example above should be the default record, to retain backward compatibility with the 7.5 behavior.
A new UI panel could change it to something like
data-cleanup=configuration AsyncRemoval=enabled GracePeriod=1 month Action=notify
AsyncRemoval=enabled works also for remote accounts provider.