Bug#949735: AWS Debian9 AMI: Problems with /etc/hosts when user-data set 'manage_etc_hosts: false'
Package: cloud.debian.org I setup an EC2 in AWS using the Debian 9 AMI. I pass along this user-data: cat /var/lib/cloud/instance/user-data.txt #cloud-config fqdn: foo.bar.cloud timezone: Europe/Stockholm manage_etc_hosts: false ssh_authorized_keys: - ssh-rsa ... Sure enough, /etc/hosts is not managed. But... 1) The created /etc/hosts file give confusing and conflicting information. It says: # Your system has configured 'manage_etc_hosts' as True. # As a result, if you wish for changes to this file to persist # then you will need to either # a.) make changes to the master file in /etc/cloud/templates/hosts.tmpl # b.) change or remove the value of 'manage_etc_hosts' in # /etc/cloud/cloud.cfg or cloud-config from user-data This is wrong. I have configured it as 'false'. I guess this erroneous information come from some default /etc/hosts template in your AMI. Action 1: Please make the header state "Your system has configured 'manage_etc_hosts' as False. Therefore this file is not managed by cloud-init." or something similar. 2) The created /etc/hosts file contain wrong IP information. It says: 127.0.1.1 ip-10-0-3-4.ec2.internalip-10-0-3-4 This is wrong. My EC2 don't have this IP. In case I do use the subnet 10.0.3.0/24, this line would confuse me since I'm not the one who added it. Again, I guess this is left-overs from some default /etc/hosts template in your AMI (you probably used IP 10.0.3.4 when creating the AMI). Action 2: Please remove this line. Or actually, see 3) below. 3) Even if I set 'manage_etc_hosts: false' I would still like the installed Debian EC2 machine to get an /etc/hosts similar to a manually installed Debian machine, using netinst or CD1. That is, I don't want /etc/hosts to be *managed* over time (after reboots), but I *do* want the initial /etc/hosts to get the line 127.0.0.1 127.0.0.1 localhost ...just like the normal debian-installer would do. Action 3: If 'manage_etc_hosts' is set to "false", do a one-time write to /etc/hosts, setting the fqdn and hostname to 127.0.0.1. Only do this the first time the EC2 is booted. After that, the file is managed manually.
Re: Contacting cloud team for hosting blends.debian.net [elb...@debian.org: Re: Any sponsoring for a VM possible (Was: Rackspace ending free hosting for blends.debian.net)]
On 2020-01-24 07:02:23, Michael Crusoe wrote: > On Fri, Jan 24, 2020, 06:18 Andreas Tille wrote: > > On Thu, Jan 23, 2020 at 08:35:30PM -0500, Noah Meyerhans wrote: > > On Thu, Jan 23, 2020 at 10:15:33PM +0100, Andreas Tille wrote: > > > > Currently the machine has 16GB memory 200GB sdd. From current usage > > > > the minimum requirement is 8GB memory (16 is certainly better since > > > > it is running a UDD clone and teammetrics database) and 80GB sdd. > > > > > > > > Is there anybody who could offer such a machine for long term usage. > > > > Yes, in general this is something we can and should do. We haven't done > > this yet in the new SPI-owned AWS accounts, which are the right ones to > > use here (assuming we decide to use AWS; obviously there are other > > options), so there are some administrative and technical details to work > > out. > > > > How soon do you need this? > > Michael was asking for prolongation but the old contract he was caring > for was ending 24 days ago (without notice to him). :-( > > I've gotten an extension to the end of the month! This month? It's 7 days, I suppose it's enough time to migrate 1 server if it's permissable to have downtime, but I'm not sure how ready we are with hosting this in one of the 'new' accounts. Looks like we have slightly bigger control over AWS then GCP accounts so probably if time is an essence AWS can be a solution. Tho, I'm not sure how the decision making process is working now (if we have one TBH). I'd say in the worst case scenario you could host it on one of the old accounts and then migrate it out to the final one if it's not ready right now. Hopefully you've got this automated :-) -- |_|0|_| | |_|_|0| "Panta rei" | |0|0|0| kuLa | gpg --keyserver pgp.mit.edu --recv-keys 0x686930DD58C338B3 3DF1 A4DF C732 4688 38BC F121 6869 30DD 58C3 38B3 signature.asc Description: PGP signature
Re: Contacting cloud team for hosting blends.debian.net [elb...@debian.org: Re: Any sponsoring for a VM possible (Was: Rackspace ending free hosting for blends.debian.net)]
On Fri, Jan 24, 2020 at 12:39:53PM +, Marcin Kulisz wrote: > I'd say in the worst case scenario you could host it on one of the old > accounts > and then migrate it out to the final one if it's not ready right now. > Hopefully you've got this automated :-) The only reason the old account would be any easier is that we don't have any expectations that the resources there are provisioned with any sort of tooling/automation, so we wouldn't feel quite so guilty about doing things by hand. It's... technically an option I guess. :) Bastian and I have talked a little bit about using Lightsail[1] within the new engineering account. It doesn't require as much infrastructure to be set up (VPCs, subnets, route tables, security groups, etc), so it isn't blocked on us updating our terraform configuration to define all these resources. Lightsail has a 4-core, 16 GB RAM, 320 GB SSD option that sounds good for this use case. There are a couple issues with Lightsail: Buster isn't available yet, so we'd need to start with a stretch instance and upgrade it. Not a show-stopper, but it adds some work. No IPv6 support. (If you have an AWS account, please contact your TAM and request this.) noah 1. https://aws.amazon.com/lightsail/
