(replying twice because I think these are two very distinct conversations) On Apr 15, 2014, at 12:19 AM, Lucas Nussbaum <leader@debian.org> wrote: <snip> > Of course, the Cloud is a specific use case, that might require changes > in the way we currently ship Debian. But those changes should be made > project-wide as much as possible, rather than limited to the Cloud > context. > I agree the cloud is a specific use case closer related to a workflow than fundamental technology limitation. In my digging to try to find a way to resolve the situation I reached out to the blends team as when I reviewed the documentation my understanding was that was the blends are more or less customized Debian versions containing possibly drastic changes to a stock install specifically to help out a user segment. It seemed quite clear to me that the cloud project is working to produce a blend. An individual very politely helped me to understand that it doesn't work the way I had modeled: blends aren't really enforced, a pure blend was a blend that moved voluntarily under the Debian project (I think I have this right, I frustrated the poor individual with not understanding nuances I think). As I tried to reconcile the difference between a community formed under blends for specific subsets of users and the work of the cloud team I caused additional confusion and though I did not intend to I was spreading around problems further than needed and achieving little more than further confusing myself. It still isn't really clear to me why the output of the cloud project isn't a Debian pure blend targeting cloud users and right now is something that looks far closer to a Wheezy install DVD. > You mention that one has to log in using 'admin' rather than 'root'. > Isn't that a rather standard change in Cloud images? > Are there other changes that you feel are not justified? > There's a variable here: the user name. Is admin common? Well it is as common as Debian is because it is the Debian specific username. The other versions I have run into are ubuntu (for their cloud products) and ec2-user. The common thing here is that each cloud OS seems to need a different username to log into the server where you'll need to execute sudo to become the superuser. I've been trying for months now to find any individual who can answer why the cloud works like this. The answer I get is "because that's the cloud security model." I follow up with "why is that the cloud security model?" and of course I get "because it increases security." To date no one can actually answer the question of: "Why does adding in a non-priviledged user with access to sudo with out further authentication required to become root increase security?" Really the admin user yak can be shaved effectively even in a heterogenous environment by introducing metadata on the server configuration which indicates the username required to execute sudo to run operations as the root user and a modification to all system administration tools built to support optionally invoking sudo and the variable username. Once shaved its not hard to maintain. One reason for having root logins disabled and forcing users to go in through a non-priviledged user and invoke sudo to become the superuser would be to train good user behavior through work flow. The model being that the default OS configuration requires the users to start solving the problems related to proper multi-user system administration tasks from the start. To put it another way when more non-priviledged users are added aside from admin the administration tools will already support execution as a non-priviledged user. This isn't really a cloud specific issue as it is good user behavior on or off the cloud. Some people are viscerally for it, some people are viscerally against it, and nobody has really done a reflective analysis of why. It seems this needs to be a topic of discussion. So far the most constructive thing I've been able to offer is to limit or stop changes on a release that looks like a Debian/Wheezy install DVD and that is not nearly as constructive as I'd like to be. My goals are to limit the disruption to end users and because of that stopping the work done so far or removing user access to the work is a mistake. The work itself is also good but there was a period of pain while it made it there. So best case scenario by far is to continue the work and continue publishing it. In my opinion the fairest option to end users is to clearly label it as being Debian Wheezy (Cloud Edition) and when this whole thing is hashed out my hope is that Debian Jessie won't even need the designation of being cloud specific. I have some reports from the trenches about architectural decisions made in the existing cloud images. Because the model the images use is that of a more or less ready to go operating system that on first boot enters multi-user mode and performs some simple bootstrap configuration such as generating ssh keys (and one of the painful things delivered that roots in churn and shouldn't have happened on something considered stable was a ssh host key accidentally shipped in the EC2 AMIs) there's some limitations that can be more difficult to work around than is necessary. On first boot the images instead could come up with out a fully completed debootstrap so that the system is executing outside of multiuser mode. On EC2 if the user data scripts executed at this point it would be far easier to do major filesystem operations such as attaching additional storage volumes because none of the daemons are online yet. As well the user data scripts would not have to worry about race conditions that show up when executing and customizing the OS heavily as can show up now. I would far prefer to be able to perform those operations before the system has ever attempted to go multiuser at all, not while it is in the middle of bringing up multiuser now. It seems though that some form of user data is a feature common to nearly all cloud providers and I've had systems doing hands off installs with per server configurations defined on keys like MAC and URL for quite a while. Its not clear to me why there needs to be a custom workflow here at all except that the existing Wheezy debootstrap may not support this exact feature which I think would be defined as "hands off network installs can be fully defined through the contents of an arbitrary string." I would rather see effort spent increasing the features available to Debian as a whole than just the Debian cloud images. Another problem that can be very difficult to deal with, especially in emergency situations, is that almost all cloud providers do not provide a feature that allows access to a console either via keyboard/video/mouse emulation or serial port emulation. The result is that single user mode is not available. It really sucks when this bites you on a production server but arguably it is a vendor specific issue: not all cloud providers lack the KVM or serial port emulation and not all of them do not allow single user mode. But this problem isn't limited to cloud servers at all. I've got the exact same issue on the old piece of trash box I leave running as a backup name server at home as it also rarely has a keyboard and video attached to it but it always has a network cable attached to it. In an emergency being able to initiate network based single user mode using a configuration defined on the network as well is a feature that is useful for all users from a beagle bone to EC2. I'm not sure what is more universal than that. I believe that would have been a far better path to go down for the Debian Cloud work than has been done to date. Though I do want least disruption which is why I think abandoning this work is out of the question entirely. I'd also like to point out again that my issue is with changes and all changes cause problems. Debian/Stable has been with out major changes for quite a while and I can't readily think of an example where I've experienced changes of this caliber before on anything that was considered Debian/Stable official images. Thanks again for taking the time to understand my concerns, Tyler
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail