Change (or not) the user's data deletion policy

(HF) #21

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.

(Davide Principi) #22

This is not the “traditional” NethServer deployment. Gabriel might record our discussions about “multi-tenant” features :wink:

…designed for small offices and medium enterprises

Will it change in the future? /cc @alefattorini

(HF) #23

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.

(Gabriel GHEORGHIU) #24

Of course I remember discussions about “multi-tenant” features. Every day! I still use Zentyal for this (missing) feature! :wink:
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:

  1. One NS for each customer (email server, web server, cloud). NS could be VM or bare metal server.
  2. 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! :wink:

(Alessio Fattorini) #25

I don’t know. Currently this is our market.

Good to know. Maybe you’re right :slight_smile:

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

(Gabriel GHEORGHIU) #26

Okay, but I do not see any impediment to do that.

(Gabriel GHEORGHIU) #27

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).

(Alessio Fattorini) #28

5 posts were split to a new topic: Make a map on how and where NS is being used

(Stéphane de Labrusse) #29

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 ?

(Davide Principi) #30

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.

(Stéphane de Labrusse) #31

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

(Giacomo Sanchietti) #32

I propose to not change current behavior: keep all user data after delete
Then, implement a semi-automatic solution:

  • create a new user-cleanup event
  • 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.

(Davide Principi) #33

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.

(Giacomo Sanchietti) #34

Yes, the delete shouldn’t remove any data. Honestly I thought it was already like this :smiley:

(Davide Principi) #35

Someone like a bot :robot:

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.

(Davide Principi) #36

New database key proposal

  • 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

     GracePeriod=1 month

AsyncRemoval=enabled works also for remote accounts provider.