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.
1 Like
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.
1 Like
I return to my mind roundabout…
- ask to the remote authentication with the script
/usr/libexec/nethserver/list-users - 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
user-cleanupevent - 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.
1 Like
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 
1 Like
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
user-cleanup) or - 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.
3 Likes
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
rm -rf.
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.
1 Like