On mar., 2012-03-20 at 01:23 +0000, Luca Filipozzi wrote: > Comrades! > > We just finished a very productive Debian System Administration team > sprint in Oslo, Norway. First, thanks for the amazing job you do. > Hosting & Virtualization > ======================== > Virtualization has come of age and we want to move most services into > virtual machines, thus reducing the overall count of physical machines. > VMs are easier to move between physical hosts and give us service > separation without too much administrative or computational overhead. > Another advantage of virtualization is it makes it easier to increase > the availability of services. However, we recognize that there are > services that will continue to need dedicated hardware due to resource > requirements and, as such, we will not be able to move everything into > VMs. > You don't speak at all of the virtualization solution. Afair xen is currently already used on part of the infrastructure. Is it the preferred choice? Did you consider the use of containers / “lightweight virtualization”? > > > User and Group Management > ========================= > > Debian has, approximately, 50 000 shell accounts [4]. We believe most > of these are unused and would therefore like to disable those that are. > The goal is to reduce the our exposure and not to take away anybody's > privileges. We will monitor shell account activity in order to identify > and disable shell accounts that have been unused for a significant > amount of time (months). We will extend ud-ldap to allow users to > easily and quickly re-enable their shell accounts. So that means something like a signed mail based “shell-knocking”? DD would need to send a gpg-signed mail to (re)enable a shell on a chosen machine before he can use it? > > Similarly, there is currently no mechanism which ensures that people > only have the group memberships which they are using. We would like to > implement a system which will require users to periodically confirm > their group memberships. Like the shell accounts, the goal is to reduce > our exposure, not to take away anybody's privileges. Shouldn't the various teams handling the group take care of managing them? Do they currently fail at that? Regards, and again thank you for all the work! -- Yves-Alexis
Attachment:
signature.asc
Description: This is a digitally signed message part