Question
Do I need cloud-init?
- Posted on May 16, 2017
- Linux BasicsUbuntu
Asked by adminc6bc084b9ac49e0d2801b
Every time I update, I see the following:
$ apt list --upgradable
Listing... Done
cloud-init/zesty 0.7.9-90-g61eb03fe-0ubuntu1 all [upgradable from: 0.7.9-0ubuntu1~16.10.1]
and when upgrading
The following packages have been kept back:
cloud-init
What is the package for and why is it held back?
DigitalOcean’s FAQ contains an entry on CloudInit:
What is CloudInit?
CloudInit is a process enabled on recent DigitalOcean images that is able to pull down and process information from metadata. When the Droplet boots for the first time, the CloudInit program executes the script it finds in the user-data field, providing users the opportunity to automate the initial configuration of their servers.
but I am not much wiser. Apparently, it is used during the initial boot but is it safe to remove it afterwards?
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.
Last I recall, DigitalOcean uses it for the imaging and snapshot setups. If you’re not going to use the snapshot / backup service, then it’s safe to remove.
Removing the package shouldn’t remove any other packages or core dependencies. When testing it on Ubuntu 16.04, only that one package is removed.
…
As for the purpose of the package, you can read over the basics here:
https://help.ubuntu.com/community/CloudInit
The above link provides more detailed information on what it can do as well as a few use cases for it.
…
That said, it’s odd that dist-upgrade would leave the package hanging. I tested this one two Droplets and neither have any packages remaining or hanging behind, kernel or otherwise.
I normally run the full suite on initial deployment:
apt update \
&& apt -y full-upgrade \
&& apt -y upgrade \
&& apt -y autoremove
Or if you prefer to use apt-get:
apt-get update \
&& apt-get -y dist-upgrade \
&& apt-get -y upgrade \
&& apt-get -y autoremove
16.04/16.10 now use apt which I find more useful since it shortens commands (even though I mostly use bash scripts).
Want to learn more? Join the DigitalOcean Community!
Join our DigitalOcean community of over a million developers for free! Get help and share knowledge in Q&A, subscribe to topics of interest, and get courses and tools that will help you grow as a developer and scale your project or business.
@jtittle
For various reasons, I prefer to have installed only the packages that are actually used. I understand how the package is employed for the initial deployment, I would like to know if it does anything once the system is set up.
…
Actually the “packages have been kept back” is an output of
dist-upgrade. I always run it since I like to live on the edge ;-)But this particular peculiarity of apt is of secondary interest to me. Mainly, I would like to make sense of the package itself.
@adminc6bc084b9ac49e0d2801b
When you first deploy a Droplet, there’s a checkbox labeled “User Data” which allows you to pass a bash script to the service, which will then run during the initial deployment. This allows you to do an initial server configuration without having to login to the terminal. It’s more useful if you’re using the API as a part of automated deployments, though it can be a quick way to simply get things setup as needed from the control panel as well.
…
Unless you absolutely need to remove it, it’s safe to leave it as-is. It’s not really taking up much disk space or utilizing large amounts of CPU or RAM (if any at all).
The reason it’s kept back is similar to how kernel updates are kept back unless you run:
The standard upgrade command:
… won’t upgrade core packages that may change functionality. For example, if you were running PHP 7.0 and PHP 7.1 was in the repositories as well, the base upgrade command won’t upgrade 7.0 to 7.1 or even 8.0 (when it’s released) as those are major version releases. It would, however, upgrade 7.0.x to 7.0.1, 7.0.2, etc. The same for other software.
Generally, unless you 100% confident you’re not going to run in to issues with a new kernel, newer versions of software, etc – you don’t want to
dist-upgrade. While it’s generally safe, it does allow major version releases to be installed.@jtittle I understand the benefits of provisioning but at the moment setting the server manually is enough. If my requirements change, I will likely go the whole way and use NixOS + NixOps.
…
I definitely did not hold the package manually. Maybe it got marked as hold during upgrade to zesty? Either way, I reinstalled it and it is no longer hold.