Does LDAP allow that too ?
It depends on too many things… Maybe a local ldap provider can be configured for that, but as openldap is deprecated in rhel 7 we have to plan for directory 389 too
Hi everybody!
My opinion about this subject.
We have three possible situations for NethServer utilisation:
- for home -> no GDPR rules. Q: are we sure?
- for commercial environment “where the data is always owned fully by the client” (as @LayLow said), generally for hosted web servers, hosted e-mail servers, hosted backups, … -> “Data of a consumer must be GDPR compliant and to be wiped in an instance on first request”.
- for company environment where “data of your employee might be owned by the company, and even if the employee left the company, you could need some of his email, files in his home, addresses of his customers, his agendas …” (as @stephdl said).
In any of the above situations we would use NethServer, I do not think an automatic data erasure solution would be indicated, at least for the reason given by @giacomo: “Less code, less bug”.
Also, I don’t think that an automatically erase mechanism will make NethServer to be GDPR compliant.
And I don’t know if a software must or can be GDPR compliant.
It’s not about “GDPR compliant”, it’s about “GDPR rules”.
As far as I know and understand, in a few words, to respect GDPR rules, means that the users data are kept safe, can be deleted by request and there is a mechanism to audit the access to these data.
NethServer keep data safe, there is at least an audit mechanism (samba audit module) and by request, the Administrator can delete data.
Best regards,
Gabriel
2 Likes
sure, the sysadmin is responsible at the end, never the nethserver project (at least I hope :D)
2 Likes
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).
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