admin is fine too... basically I just wanted Debian to have their own default user that wasn't the same as other OSes use. IE: I don't love ec2-user because people following docs out there with ec2-user would be following docs for a different OS, and having it be the same as the Amazon Linux AMIs (which are CentOS based) might end up being more confusing than helpful.
-Brian--On Sat, Nov 10, 2012 at 10:32 AM, Anders Ingemann <firstname.lastname@example.org> wrote:
> I think that it is important to underline that the account is privileded. How about 'Administrator' ? Seriously.It's a bit long to type. "admin"? I can change that in the bootstrapper pretty quickly.I think this could be a username pretty much every cloud provider and distribution could agree on.
On 9 November 2012 00:39, Charles Plessy <email@example.com> wrote:Hello everybody,
Le Thu, Nov 08, 2012 at 10:38:07AM +0000, Bromberger, James a écrit :
>I think that it is important to underline that the account is privileded.
> 1) SSH Username: 'debian' is an obvious choice. Ec2-user is the other. Time
> for an informal vote here?
How about 'Administrator' ? Seriously.
> 3) cloud-init - yes, but it's going to be some years for stable/main. Charles
> - your thoughts?
Help ! http://lists.debian.org/debian-cloud/2012/11/msg00003.html
> 4) CLI tools - not initially here. There's lots to discuss with regards to
> packages of it; who should maintain it, what is the copyright, and where
> should the repo be. I would love to, but I don't have answers for those
> questions right now.
They are non-free, so I think that we should not have them by default.
Packaging them in the non-free section if the license allows would be a good
compromise. Then, scripts ą la cloud-init could be turned on to enable
auto-updates for the users who want to.
We also have the euca2ools, which do not implement all the API (no
'--instance-initiated-shutdown-behavior terminate' yet, for instance), but they
are Free and patches may be welcome. https://github.com/eucalyptus/euca2ools
> 9) It was not a Debian security issue - but an image generation that left a
> X509 key visible in the block device.
That is one of the reasons why I like my approach with Debian Installer: 1)
install Debian on a EBS volume in the cloud and 2) bless that volume from
outside the cloud, so that no password or private key transits on the installer
or installed system.
Have a nice day,
Tsurumi, Kanagawa, Japan
Archive: 20121108233906.GB22290@falafel.plessy.net" target="_blank">http://lists.debian.org/20121108233906.GB22290@falafel.plessy.net
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com