Re: dhcpcd is gone on Jessie, which DHCP client is recommended for Jessie Debian AMIs?

[Vincent Bernat]

 ❦  5 août 2014 22:56 +0200, Tomasz Rybak tomasz.ry...@post.pl :

 I'm testing bootstrap-vz and it would like to install dhcpcd but it is
 not present on Jessie.
 isc-dhcp-client and isc-dhcp-common are intentionally excluded during
 bootstrapping and our wiki also recommends avoiding them:
 https://wiki.debian.org/Cloud/CreateEC2Image
 
 Which DHCP client is packaged and known to work in Jessie?

 dhcpcd5.
 This is known problem and is fixed in development branch
 of bootstrap-vz. Fix was in PR #118:
 https://github.com/andsens/bootstrap-vz/pull/118

Why is isc-dhcp-client not recommended?
-- 
Take care to branch the right way on equality.
- The Elements of Programming Style (Kernighan  Plauger)


signature.asc
Description: PGP signature

Re: bootstrap-vz switching to single branch strategy

[Vincent Bernat]

 ❦  3 mai 2015 04:43 +0200, Eirik Schwenke debian-li...@s.hypertekst.net :

 I was wondering; are there any plans to make it more usable as a
 regular user? It seems it shouldn't be necessary to run it as root (at
 least not in all use-cases)?

Have a look at unshare which allows to become root without any
privilege. However, you need to set kernel.unprivileged_userns_clone to
1.
-- 
Make it clear before you make it faster.
- The Elements of Programming Style (Kernighan  Plauger)


signature.asc
Description: PGP signature

Re: Debian images on Microsoft Azure cloud

[Vincent Bernat]

 ❦ 12 novembre 2015 16:34 +0100, Thomas Goirand  :

>>> I just created wiki page[1] where we could put those requirements. It's
>>> simple but should do the job.
>>>
>>> 1. https://wiki.debian.org/Cloud/Images_requirements
>> 
>> Currently, both the Openstack images and the image built for Azure are
>> using extlinux instead of Grub. I think this is mostly due to a personal
>> preference from Zigo. extlinux works fine but this is a deviation of
>> what a user would expect of a regular Debian installation.
>> 
>> Should cloud images be allowed to change the bootloader?
>
> Definitively, yes. Please propose patches.

I am fine with this deviation (and don't have time either). Moreover,
other systems, notably bootstrap-vz, already have this possibility. I
think work should not be done in multiple places and I would favor
bootstrap-vz whenever possible (but currently, your Openstack images are
the most official ones, so I am using them and they are working just
fine; on our platform, they boot in less than 15 seconds, cloud-init
included).
-- 
All things that are, are with more spirit chased than enjoyed.
-- Shakespeare, "Merchant of Venice"


signature.asc
Description: PGP signature

Re: Debian images on Microsoft Azure cloud

[Vincent Bernat]

 ❦ 11 novembre 2015 17:49 GMT, Marcin Kulisz  :

>> I would suggest we open a seperate thread on the debian-cloud mailing
>> list for defining a list of official requirements for all vendors. As
>> long as we define the first version of that list i would suggest though
>> that those are nice to have for the Azure (and all other) images but
>> will not block us from releasing the images.
>
> I just created wiki page[1] where we could put those requirements. It's
> simple but should do the job.
>
> 1. https://wiki.debian.org/Cloud/Images_requirements

Currently, both the Openstack images and the image built for Azure are
using extlinux instead of Grub. I think this is mostly due to a personal
preference from Zigo. extlinux works fine but this is a deviation of
what a user would expect of a regular Debian installation.

Should cloud images be allowed to change the bootloader?
-- 
Don't patch bad code - rewrite it.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Cloud images with backports APT-enabled.

[Vincent Bernat]

 ❦ 30 novembre 2015 22:31 +0900, Charles Plessy  :

>> > In the case of cloud images, wouldn't that problem be solved by pinning the
>> > backports suite at a low priority, and pinning the installed backports
>> > (cloud-init, etc.) at a higher priority ?
>
> Le Sat, Nov 28, 2015 at 09:23:31PM +0100, Thomas Goirand a écrit :
>> 
>> Even with such pinning, the problem you mentioned would remain, no?
>
> Not the same, but still a problem.
>
> If stable-backports is pinned to -1, packages will not be installed even if 
> they
> are not in the base suite, but there will be no updates.

No need to pin backports. The release file contains "NoAutomatic: yes"
and "ButAutomaticUpgrades: yes". So, this should do what a user expects
automatically.
-- 
Use debugging compilers.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: About non-Stable files in Cloud images: create a Blend ? Distribute image builders on ftp.debian.org ? More liberal Stable updates ? (Re: Debian images on Microsoft Azure cloud)

[Vincent Bernat]

 ❦ 26 novembre 2015 08:25 -0500, Brian Gupta  :

>> On the Stable release, we have updates for the Kernel to add new
>> drivers, previously not supported. I really consider that the support of
>> new clouds (for example through an update of cloud-init) is exactly the
>> same kind of thing. Cloud-init is IMO just like a driver for the cloud,
>> which we should be allowed to update, just like for the kernel, and as
>> soon as the diff is minimal. I have very little hope for introducing a
>> new upstream release (I'm almost sure the release team would just refuse
>> that), though perhaps we can do a bit patch of backports.
>>
>> Your thoughts anyone?
>
> I think that if PPAMAIN existed we might not be having this
> discussion. (Or at the very least it would be a much shorter
> conversation.)
>
> As you know, public and private cloud APIs move at a much faster rate
> than our ~2-3 year release cadence.
>
> We all need a way to bring in newer cloud enablement packages. It
> seems to me our theoretical options are either via backports,
> stable-updates, or PPAMAIN, as I don't think convincing the release
> team to make an exception for cloud enablement packages is likely to
> work. Perhaps they will grant us an exception, where the package in
> question is completely broken, but even then it will likely be an
> uphill battle, as we are likely to have dependencies that also need
> updating.

It is not that a fast-paced environment. To drive its adoption among
cloud users, Ubuntu frequently backports updates to their version of
cloud-init to accomodate incompatibilities that may arise. Since the
initial release of Precise, there have been 22 releases for the
cloud-init package:

 
http://changelogs.ubuntu.com/changelogs/pool/main/c/cloud-init/cloud-init_0.6.3-0ubuntu1.22/changelog
-- 
Make it clear before you make it faster.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Debian images on Microsoft Azure cloud

[Vincent Bernat]

 ❦ 23 novembre 2015 00:28 GMT, Steve McIntyre  :

> That's a very good question, and one I'll admit that I'd not paid much
> attention to. Unless the images are set up to auto-update at boot (is
> that a sensible thing? Do any of the published images do this?)

Yes, it is part of cloud-init. It is disabled by default, as far as I
know:

https://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config.txt
-- 
Repartee is something we think of twenty-four hours too late.
-- Mark Twain


signature.asc
Description: PGP signature

Re: Building cloud images on Debian infrastructure

[Vincent Bernat]

 ❦  1 avril 2016 00:13 +0200, Thomas Goirand  :

>> See Riku's talk at DebConf Heidelberg - there are many tools and
>> it would be generally better for customized tools to give way to
>> generalist tools which can use wrappers or enhancements to provide the
>> remaining functionality.
>
> I don't agree. Better for what? Specialized tools do what they do well.
> Generalist tools are over-engineered. To the contrary,
> openstack-debian-images is composed of a unique, very small shell
> script, easy to hack.

There are many choices that are quite discutable in those
images. Notably, the choice of extlinux without any proper
integration. This is a pain to get another kernel or just to change a
few boot parameters. An official Debian image should use grub2. As far
as I understand, the choice of extlinux is because it's easier to
install. Other tools are able to use grub2.

I just noticed that it is using ext3 instead of ext4 too (just opened a
bug about this).

I am happy to have those images instead of nothing but it doesn't seem
to be the state of the art of what a Debian cloud image is. Of course,
this has nothing to do with its size.

> And by the way, if we were to use a generalist tools, I'd certainly vote
> for diskimage-builder, which really, does a lot (really a lot) and is
> really modular. If there's one tool to work on so it becomes *the*
> generalist solution, then it's that one.

Didn't know about this one. It seems nice and flexible if you need to
handle different distributions. However, "generalist tools are
over-engineered". It would be simpler to use a Debian-only tool for
Debian images.
-- 
Water, taken in moderation cannot hurt anybody.
-- Mark Twain


signature.asc
Description: PGP signature

Re: Call for Testing: Stretch Cloud Images on AWS

[Vincent Bernat]

 ❦  2 février 2017 21:42 -0800, Noah Meyerhans  :

>> overall the image looks fine, no extraneous things, sysctl is clean,
>> etc. great job. :)
>
> Interesting that you bring up sysctl. I consider it a bug that we're
> currently running with an unmodified set of sysctl variables. Apparently
> you disagree. My reasoning is that the kernel defaults are intended to
> be very broadly applicable, but the cloud AMI is a more specific use
> case and it should be possible to provide a more appropriate set of
> defaults for various settings. We can tune our sysctl settings towards
> server optimizations because we know we're not running on a device like
> a laptop or mobile device.

There is no such things as an universal sysctl settings for servers. The
ones set for EC2 are quite reasonable but still debatable and different
from default settings.

For example, the change to ip_local_port_range may come to a surprise
for some users if they are using some strict local firewalls. It could
also prevent a daemon to bind to a "medium" port that was expected to be
free because outside of the default range.

Another example is the tuning on tcp_wmem/rmem. A server using a lot of
sockets will suddenly use more memory (12 MB per socket instead of 16
KB). The backlog change is similar. A user may expect its clients to
fail early when the server is unable to dequeue requests fast enough,
notably when the clients are load-balancing reverse proxy and latency is
important.

The kernel documents net.ipv4.tcp_tw_reuse as a dangerous setting to
change (and they don't want to change this wording). I know this is not
true, but some users may feel that if kernel developers say this setting
should stay to 0, why Debian does provide images with a different
setting?

At least, a comment should be added on top of the file stating those
changes are advices from Amazon for their platform.
-- 
Take care to branch the right way on equality.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Building OpenStack images with bootstrap-vz and cloud-init ?

[Vincent Bernat]

 ❦  7 février 2017 15:49 GMT, Jeremy Stanley  :

>> This may be true post jessie, but AFAIU, the 'OpenStack' data source isn't
>> supported out of the box in Jessie's version of cloud-init (see
>> #841315), and one may have to explicitely customize with a change of the
>> config file for it to be fully recognized. Still, ConfigDrive or the Ec2
>> may be enough, depending on the target cloud.
>
> For that matter, "good" (in my opinion) OpenStack service providers
> hand out relevant network configuration via DHCP/SLAAC which
> shouldn't need any special handling at all.

Does this include SSH keys and user data?
-- 
Use statement labels that mean something.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Building OpenStack images with bootstrap-vz and cloud-init ?

[Vincent Bernat]

 ❦  1 février 2017 19:05 +0100, Olivier Berger 
 :

> I have already some basic knowledge of bootstrap-vz, which I've used
> with VirtualBox and Vagrant providers, thanks. But I'm wondering whether
> anyone documented the specifics of OpenStack.
>
> Maybe you're missing some specifics of deploying the VM on the OpenStack
> IaaS, which requires some provisioning at first boot (like setting some
> specific way to connect to that specific VM instance: IP address and
> user password for instance... well I'm guessing here, actually, as I
> haven't checked how OpenStack does that).
>
> AFAIU, that's the job that cloud-init does. And as there may be other
> nifties involved, that's why I asked.

cloud-init just has to be installed. There is nothing else special to
do. The OpenStack provider is enabled by default. You can however
restrict the list to "ConfigDrive, OpenStack" for a faster boot (either
with debconf, cloud-init/datasources or by overwriting
/etc/cloud/cloud.cfg.d/90_dpkg.cfg).

Also, there are precompiled images available (but not built with
bootstrap-vz):
 http://cdimage.debian.org/cdimage/openstack/
-- 
Choose variable names that won't be confused.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Adding symbolic links for "current" images

[Vincent Bernat]

 ❦ 18 novembre 2016 08:02 +0100, Martin Zobel-Helas  :

> What i would be willing to accept thought, would be a
> /current-8/debian-current-openstack-amd64.qcow2 link which points to the
> latest Debian Jessie image. That way people will not need to ajust their
> scripts once we do a point release for minor updates of the images.

I would also like this option. As Mohammed, I am using a CI script to
fetch and test the images.
-- 
As flies to wanton boys are we to the gods; they kill us for their sport.
-- Shakespeare, "King Lear"


signature.asc
Description: PGP signature

Re: vmdb2: vmdebootstrap rewrite in progress

[Vincent Bernat]

 ❦ 29 mars 2017 14:04 +0300, Lars Wirzenius  :

> Current status is that it builds a Debian image (assuming you're
> running vmdb2 on amd64), but doesn't install a bootloader. My attempts
> to get grub-install to work have resulted in my laptop's bootloader
> being inadvertently reinstalled. If anyone would like to help with
> that, I'd be most grateful.

Maybe you can find some clues here:
 
http://sources.debian.net/src/openstack-debian-images/1.17/build-openstack-debian-image/#L597
-- 
Indent to show the logical structure of a program.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#865611: non-free repositories are enabled by default

[Vincent Bernat]

 ❦ 23 juin 2017 13:46 GMT, Joonas Kylmälä  :

> Thank you Vincent for taking a look onto this issue. I identified that
> at least these two files enable non-free software:
> templates/sources.list.ubuntu.tmpl and
> templates/sources.list.debian.tmpl. In Ubuntu's case the restricted,
> partner and multiverse repositories should be disabled in my opinion.
> About Universe repository I am not sure. In Debian's case the contrib
> and non-free repositories should be disabled.
>
> The bug itself is easy to fix (just remove those non-free repositories
> from the two files) but I don't know how to create a patch for Debian
> packages – help wanted!

debcheckout cloud-init

Then, you get a git repository. For a one-time patch, the easiest way is
to just modify the files, commit the change and then use "git-format
patch -1" to get a patch to attach to this bug report.
-- 
Parenthesise to avoid ambiguity.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#865611: non-free repositories are enabled by default

[Vincent Bernat]

Package: cloud-init
Version: 0.7.9-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi!

By default, cloud-init enables the non-free repositories. It
shouldn't. I even wonder if this should not be fixed in
stable/oldstable too.

- -- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (101, 
'experimental-debug'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.11.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cloud-init depends on:
ii  debconf [debconf-2.0]  1.5.61
ii  gdisk  1.0.1-1
ii  ifupdown   0.8.19
ii  init-system-helpers1.48
ii  lsb-base   9.20161125
ii  lsb-release9.20161125
ii  net-tools  1.60+git20161116.90da8a0-1
ii  procps 2:3.3.12-3
ii  python33.5.3-1
pn  python3-configobj  
ii  python3-jinja2 2.9.6-1
pn  python3-jsonpatch  
pn  python3-oauthlib   
pn  python3-prettytable
ii  python3-requests   2.12.4-1
ii  python3-six1.10.0-4
ii  python3-yaml   3.12-1

cloud-init recommends no packages.

cloud-init suggests no packages.

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAllMrWASHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5LbMP/jFCPa11w8sz3IkDi0CneC+iv0aX5uIA
Tc16OEV2dfLgQkYwtMecbgqrCaNAL6UfXeyDKPfkkh9Um4EzFgFALZQV1I3pjNi2
TCGOky0dOVLvWn7LUgJeVNFNNatKYLYJ8LIl5rzDCzA/hCtk230zhB0MXsgYzcvk
Ba4j0vVW2x05KC7pioBNtgYUrlgcx5X5xJGQZT2xpsux1eKI0ano+C4RvBxWSODA
fbhRGDDJ4E66PcPe/Hsyy3ZDtiEZIsvFJ10UTPlEop2t3wtZCR+7q00+Quzis/Wb
3TDvH+C/dY7AGVv1SkAa3a48J7syHGicf1pVYKFanDa+RmzDjC1IcjuJJm+VeabY
fuNNdTHlnrjXwnPJ8iIKovMdZLyUsWJaEKxf0nQIUXbbnuDvtj20znwNJ7+9SUtP
ExiVuouG7yIx546Uw6XmmWdbsOIn0Sil6AgkEgr1Veh0D8/dHSBBbLUHHxlk8G/d
WveF80ZXOgP1xjVOURmyN4UjpGQ35FOiUhLFmsN7O+a67dA527+cV3Zc/qKXaAcZ
DqHe57BnmnxH45sfFsYe2u9rY/atYlKFKzvGEjiLroBIJvO0Xkf/1fqEgvoHV+0u
53/59uMTnbCjlAbcj64xVaYdsiXStHt6Y1uvOr63WW5PzaUmG8AijiEtriGEJ6cZ
RtGUpmvWBDNQ
=qG8n
-END PGP SIGNATURE-

Bug#865611: non-free repositories are enabled by default

[Vincent Bernat]

 ❦ 23 juin 2017 15:13 GMT, Joonas Kylmälä  :

> thanks Vincent for the help you gave about creating a patch! The patch
> is attached to this email. I'm pretty confident with the modifications
> to "sources.list.debian.tmpl" but for "sources.list.ubuntu.tmpl" I would
> like to get your opinions on how to edit it. The official Ubuntu 17.04
> with default installation appears to be enabled with main, restricted,
> universe, multiverse repositories.

For Ubuntu, they maintain their own packaging for cloud-init, so it
doesn't matter.
-- 
Program defensively.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Systemd predictive network interface names for Stretch

[Vincent Bernat]

 ❦  1 juin 2017 11:38 -0700, Zach Marano  :

> I haven't found the definitive answer to this question yet. Does Stretch
> use predictive network interface names and systemd-networkd by
> default?

Predicitive network interface names are enabled by default. However,
systemd-networkd is not enabled by default (user can enable it with
"systemctl enable systemd-networkd").
-- 
There is no distinctly native American criminal class except Congress.
-- Mark Twain


signature.asc
Description: PGP signature

Re: Systemd predictive network interface names for Stretch

[Vincent Bernat]

 ❦  1 juin 2017 13:23 -0700, Zach Marano  :

> So does this mean you still need to hard code the interface names (which
> for all intents and purposes may not be static across different hardware)
> into /etc/network/interfaces when using predictive network interface names?
> This isn't the worst thing in the world for the cloud use case as the
> virtual hardware is basically consistent- but I could imagine problems in
> other circumstances or if the PCI devices change over time.

Yes, this happens. The network provider can for example provide a
balloon driver that would push the network card into a different
position. However, cloud-init handles that by writing the appropriate
ifup snippet.

> Generally, to the debian-cloud folks, what are your thoughts here for
> Debian cloud images. The possibility that PCI devices can change is always
> on the table and we shouldn't assume it can't happen in any given
> virtualization environment. If the configs for networks are hard coded we
> would risk breaking instances. Is using systemd-networkd something Debian
> is going to support going forward instead of ifup?

This would be a heated debate, unfortunately...
-- 
Use library functions.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Jessie openstack image updated to version 8.10.3-20180110

[Vincent Bernat]

 ❦ 10 janvier 2018 12:05 GMT, Steve McIntyre  :

> 8.10.3-20180110
>
> Updates in 1 source package(s), 1 binary package(s):
>
>   Source linux-latest, binaries: linux-image-amd64:amd64  
>   linux-latest (63+deb8u1) jessie-security; urgency=medium
>   
> * Update to 3.16.0-5
> (Main reason: KAISER/KPTI changes, see the linux-image-3.16.0-5-* 
> changelog for more)
>
> https://cloud.debian.org/images/openstack/current-8/

For me, the kernel is not up-to-date. Maybe you built the image while
the metapackage wasn't up-to-date.
-- 
Identify bad input; recover if possible.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Using disk images from cloud.debian.org

[Vincent Bernat]

 ❦ 17 novembre 2019 23:40 +01, Johannes Schauer :

> As I explained in the first paragraph of my initial email, I'm trying to find
> an alternative to creating a bootable disk image myself that I can then use on
> salsa CI runners (for example inside autopkgtests). So there is no metadata
> server.

You can provide the metadata as an USB disk. It's called "config drive".
See: 

-- 
You tread upon my patience.
-- William Shakespeare, "Henry IV"


signature.asc
Description: PGP signature

Re: Using disk images from cloud.debian.org

[Vincent Bernat]

 ❦ 18 novembre 2019 15:46 +01, Johannes Schauer :

> Unfortunately, it doesn't help in my situation because my original problem is
> that due to missing functionality (like losetup, mount or kpartx) in the
> autopkgtest runners I cannot create disk images so I cannot create a disk 
> image
> of that "config drive" usb stick either. :(

Without being root, you can create FAT filesystems using raw images with
mtools. For example :

truncate -s 10M metadata-$name.img
mkfs.vfat metadata-$name.img
mcopy -i metadata-$name.img id_rsa.pub ::/.

-- 
April 1

This is the day upon which we are reminded of what we are on the other three
hundred and sixty-four.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"


signature.asc
Description: PGP signature

Re: Debian VM Agent Issue

[Vincent Bernat]

 ❦  2 juin 2020 15:17 +02, Bastian Blank:

> [ The original mail was sent to use privately ]
>
> Hi Jared
[...]

I think you forgot to put him in copy. Or maybe Bcc?

> This is the result if incompatible dependencies in the agent and Gnome.
> waagent for now requires ifupdown as the network implementation, as it
> calls ifup and ifdown.  The Gnome meta-package wants to install
> network-manager, which conflicts with ifupdown.

This doesn't seem to be the case. I am using both ifupdown and
network-manager since years.
-- 
Use the fundamental control flow constructs.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature