Summary

The "Design" page at https://netplan.io/design shows a "Complex Example" of a netplan yaml config file. But it appears that the indentation of the example is incorrect on this page.

Process

Compare the indentation in "Complex example" at https://netplan.io/design/ with the indentation of the same example at https://netplan.io/reference/

Current and expected result

The "Design" page at https://netplan.io/design shows a "Complex Example" of a netplan yaml config file. But it appears that the indentation of the example is incorrect. Specifically, the "id0: definition is incorrect, as a level of indentation is lost with the "macaddress:" line in that stanza and cascades through the rest of the "id0" stanza, leaving everything below it also missing a level of indentation. "wakeonline:" is at the same indentation level as "id0:" rather than "match:"

A very similar example can be found at https://netplan.io/reference, and in that instance, the indentation appears to be correct. Search the page for "wakeonlan: true" to get to the example in question.

Summary

The section: https://netplan.io/examples/#using-multiple-addresses-on-a-single-interface says that aliases aren't supported by netplan. However netplan 0.100 added support for aliases: https://bugs.launchpad.net/ubuntu/+source/nplan/+bug/1743200

Current and expected result

The documentation should remove the section stating aliases aren't supported and ideally add an example showing how to use an aliased interface with netplan.

Summary

Tables of contents disappear as you scroll the pages.

Process

1. Go to the Reference, Design, Examples, FAQ or Troubleshooting pages.
2. Click on an element from the table of contents or scroll down the page.

Current and expected result

The TOC disappears; it’s difficult to see where you are. The text on the left is still constrained to let a table of contents be on the right side.
The TOC is sticky in https://ubuntu.com/legal/data-privacy, for example.

Summary

The FAQ How to go back to ifupdown
is not fully comprehensive and/or satisfactory.

The text there says:

netplan can be removed by installing ifupdown and configuring /etc/network/interfaces manually

Though that is exactly what I have done, this morning I have experienced that my server has ignored settings in /etc/network/interfaces (i.e. a static IP configured) and, driven by the systemd-networkd service, it asked for a DHCP lease (thus losing the static IP)!

Probably some additional reconfigurations are needed (maybe disable systemd-networkd.service ?).

Process

Following the instructions in the FAQ at issue, I have installed ifupdown and have manually configured /etc/network/interfaces to set a static IP on the eth0 device.

At some point (I still haven't figured why), the static IP has been ignored and the system asked for a DHCP lease!

After rebooting the server, the static IP worked again.
Anyway, at this point, I cannot fully trust that FAQ: in order to avoid this problem happens again, I need to change some other settings on the system.

As an example, I have found a detailed procedure here.
Please, note that I have not tested that yet; anyway, just reading at it, that could work.

Current and expected result

I expected the server to keep the static IP as configured in /etc/network/interfaces.
Indeed that worked for several months... until this morning.

Today I have found the server got its IP changed by a DHCP request, which has been started by the systemd-networkd daemon, during the daily scheduled standard operations.

Screenshot

Here follows an extract from the syslog file.
Look at the last 6 lines.

Feb  7 06:32:28 myhostname systemd[1]: Reexecuting.
Feb  7 06:32:28 myhostname kernel: [588033.424143] printk: systemd: 36 output lines suppressed due to ratelimiting
Feb  7 06:32:28 myhostname kernel: [588033.428817] systemd[1]: systemd 237 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid)
Feb  7 06:32:28 myhostname kernel: [588033.428888] systemd[1]: Detected virtualization microsoft.
Feb  7 06:32:28 myhostname kernel: [588033.428893] systemd[1]: Detected architecture x86-64.
Feb  7 06:32:28 myhostname systemd[1]: Stopped Wait for Network to be Configured.
Feb  7 06:32:28 myhostname systemd[1]: Stopping Wait for Network to be Configured...
Feb  7 06:32:28 myhostname systemd[1]: Stopping Network Service...
Feb  7 06:32:28 myhostname systemd[1]: Starting resolvconf-pull-resolved.service...
Feb  7 06:32:28 myhostname systemd[1]: Started resolvconf-pull-resolved.service.
Feb  7 06:32:28 myhostname systemd[1]: Stopped Network Service.
Feb  7 06:32:28 myhostname systemd[1]: Starting Network Service...
Feb  7 06:32:28 myhostname systemd[1]: Starting resolvconf-pull-resolved.service...
Feb  7 06:32:28 myhostname systemd[1]: Started resolvconf-pull-resolved.service.
Feb  7 06:32:28 myhostname systemd-networkd[62327]: veth4da5ee7: Gained IPv6LL
Feb  7 06:32:28 myhostname systemd-networkd[62327]: vethad0a3be: Gained IPv6LL
Feb  7 06:32:28 myhostname systemd-networkd[62327]: vethcd55d16: Gained IPv6LL
Feb  7 06:32:28 myhostname systemd-networkd[62327]: vethf613965: Gained IPv6LL
Feb  7 06:32:28 myhostname systemd-networkd[62327]: veth5405e52: Gained IPv6LL
Feb  7 06:32:28 myhostname systemd-networkd[62327]: vethaac7262: Gained IPv6LL
Feb  7 06:32:28 myhostname systemd-networkd[62327]: veth6a82578: Gained IPv6LL
Feb  7 06:32:28 myhostname systemd-networkd[62327]: veth587b636: Gained IPv6LL
Feb  7 06:32:28 myhostname systemd-networkd[62327]: veth743f4eb: Gained IPv6LL
Feb  7 06:32:28 myhostname systemd-networkd[62327]: veth0c4a7b0: Gained IPv6LL
Feb  7 06:32:28 myhostname systemd-networkd[62327]: veth167b120: Gained IPv6LL
Feb  7 06:32:28 myhostname systemd-networkd[62327]: vethb939fbc: Gained IPv6LL
Feb  7 06:32:28 myhostname systemd-networkd[62327]: veth3b694b5: Gained IPv6LL
Feb  7 06:32:28 myhostname systemd-networkd[62327]: docker_gwbridge: Gained IPv6LL
Feb  7 06:32:28 myhostname systemd-networkd[62327]: docker0: Gained IPv6LL
Feb  7 06:32:28 myhostname systemd-networkd[62327]: eth0: Gained IPv6LL
Feb  7 06:32:28 myhostname systemd-networkd[62327]: Enumeration completed
Feb  7 06:32:28 myhostname systemd[1]: Started Network Service.
Feb  7 06:32:28 myhostname systemd[1]: Starting Wait for Network to be Configured...
Feb  7 06:32:28 myhostname systemd[1]: Starting resolvconf-pull-resolved.service...
Feb  7 06:32:28 myhostname systemd[1]: Stopping Network Name Resolution...
Feb  7 06:32:28 myhostname systemd-networkd[62327]: veth587b636: Link is not managed by us
Feb  7 06:32:28 myhostname systemd-networkd[62327]: docker0: Link is not managed by us
Feb  7 06:32:28 myhostname systemd-networkd[62327]: docker_gwbridge: Link is not managed by us
Feb  7 06:32:28 myhostname systemd-networkd[62327]: veth743f4eb: Link is not managed by us
Feb  7 06:32:28 myhostname systemd-networkd[62327]: lo: Link is not managed by us
Feb  7 06:32:28 myhostname systemd-networkd[62327]: veth4da5ee7: Link is not managed by us
Feb  7 06:32:28 myhostname systemd-networkd[62327]: vethad0a3be: Link is not managed by us
Feb  7 06:32:28 myhostname systemd-networkd[62327]: veth5405e52: Link is not managed by us
Feb  7 06:32:28 myhostname systemd-networkd[62327]: veth3b694b5: Link is not managed by us
Feb  7 06:32:28 myhostname systemd-networkd[62327]: vethcd55d16: Link is not managed by us
Feb  7 06:32:28 myhostname systemd-networkd[62327]: vethf613965: Link is not managed by us
Feb  7 06:32:28 myhostname systemd-networkd[62327]: veth6a82578: Link is not managed by us
Feb  7 06:32:28 myhostname systemd-networkd[62327]: veth167b120: Link is not managed by us
Feb  7 06:32:28 myhostname systemd-networkd[62327]: veth0c4a7b0: Link is not managed by us
Feb  7 06:32:28 myhostname systemd-networkd[62327]: vethb939fbc: Link is not managed by us
Feb  7 06:32:28 myhostname systemd-networkd[62327]: vethaac7262: Link is not managed by us
Feb  7 06:32:28 myhostname systemd[1]: Started resolvconf-pull-resolved.service.
Feb  7 06:32:28 myhostname systemd[1]: Starting resolvconf-pull-resolved.service...
Feb  7 06:32:28 myhostname systemd[1]: Stopped Network Name Resolution.
Feb  7 06:32:28 myhostname systemd[1]: Starting Network Name Resolution...
Feb  7 06:32:28 myhostname systemd[1]: Started resolvconf-pull-resolved.service.
Feb  7 06:32:28 myhostname systemd-resolved[62386]: Positive Trust Anchors:
Feb  7 06:32:28 myhostname systemd-resolved[62386]: . IN DS 19036 8 2 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5
Feb  7 06:32:28 myhostname systemd-resolved[62386]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
Feb  7 06:32:28 myhostname systemd-resolved[62386]: Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21.172.in-addr.arpa 22.172.in-addr.arpa 23.172.in-addr.arpa 24.172.in-addr.arpa 25.172.in-addr.arpa 26.172.in-addr.arpa 27.172.in-addr.arpa 28.172.in-addr.arpa 29.172.in-addr.arpa 30.172.in-addr.arpa 31.172.in-addr.arpa 168.192.in-addr.arpa d.f.ip6.arpa corp home internal intranet lan local private test
Feb  7 06:32:28 myhostname systemd-resolved[62386]: Using system hostname 'myhostname'.
Feb  7 06:32:28 myhostname systemd[1]: Started Network Name Resolution.
Feb  7 06:32:28 myhostname systemd[1]: Starting resolvconf-pull-resolved.service...
Feb  7 06:32:28 myhostname systemd[1]: Stopping Network Time Synchronization...
Feb  7 06:32:28 myhostname systemd[1]: Stopped Network Time Synchronization.
Feb  7 06:32:28 myhostname systemd[1]: Starting Network Time Synchronization...
Feb  7 06:32:28 myhostname systemd[1]: Started resolvconf-pull-resolved.service.
Feb  7 06:32:28 myhostname systemd[1]: Started Network Time Synchronization.
Feb  7 06:32:28 myhostname systemd[1]: Stopped Flush Journal to Persistent Storage.
Feb  7 06:32:28 myhostname systemd[1]: Stopping Flush Journal to Persistent Storage...
Feb  7 06:32:28 myhostname kernel: [588033.832608] systemd[1]: Stopping Journal Service...
Feb  7 06:32:28 myhostname kernel: [588033.834097] systemd-journald[505]: Received SIGTERM from PID 1 (systemd).
Feb  7 06:32:28 myhostname kernel: [588033.843252] systemd[1]: Stopped Journal Service.
Feb  7 06:32:28 myhostname kernel: [588033.845242] systemd[1]: Starting Journal Service...
Feb  7 06:32:28 myhostname kernel: [588033.936744] systemd[1]: Started Journal Service.
Feb  7 06:32:28 myhostname systemd[1]: Starting Flush Journal to Persistent Storage...
Feb  7 06:32:28 myhostname systemd[1]: Started Flush Journal to Persistent Storage.
Feb  7 06:32:29 myhostname systemd-networkd[62327]: eth0: DHCPv4 address 192.168.13.103/24 via 192.168.13.254
Feb  7 06:32:29 myhostname systemd-networkd[62327]: eth0: Configured
Feb  7 06:32:29 myhostname systemd-timesyncd[62422]: Network configuration changed, trying to establish connection.
Feb  7 06:32:29 myhostname systemd-networkd-wait-online[62355]: managing: eth0
Feb  7 06:32:29 myhostname systemd-networkd-wait-online[62355]: ignoring: lo
Feb  7 06:32:29 myhostname systemd[1]: Started Wait for Network to be Configured.

Summary

Documentation includes raw XML tags which web browsers are failing to display properly. The tags should be properly encoded for the browser display.

Process

The documentation at https://netplan.io/examples/ displays the following content to the end user, about halfway down the page:

The name of the bridge in the tag as well as in need to match the name of the bridge device configured using netplan:

If you look at the code using the browser's "inspect" option, you'll see that there appears to be documentation content that's being interpreted as HTML tags.

The name of the bridge in the <bridge> tag as well as in <name> need to match the name of the bridge device configured using netplan:

This is the only example of such misencoding that I've found, but I haven't looked for other examples, specifically.

Current and expected result

These XML tags in the documentation should be properly encoded for HTML display.

Reproduced in multiple browsers on multiple devices.

Screenshot

I believe these examples are wrong. addresses and routes are being specified directly under ethernets instead of under an example interface name under ethernets.

Summary

The example given at https://netplan.io/examples#bridging shows a complete netplan yaml which does not validate, because it defines a bridge which references an ethernet interface which is not declared.

This led to https://askubuntu.com/questions/1096089/netplan-bridge-issue/1098585#1098585 asked by a user.

The example given for a bridge should be as simple as possible but no simpler.

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

Error type: undefined

Summary

Design page references curtin/MAAS's v1 format but does not provide link

Process

[list the steps to replicate the issue]

Current and expected result

When users read about v1, it should provide a link for more details.

http://curtin.readthedocs.io/en/latest/topics/networking.html

Screenshot

[if relevant, include a screenshot]

Summary

On at least Ubuntu 18.04, the example given at https://netplan.io/examples#configuring-source-routing does not seem to fully describe how to configure source based routing.

Process

Copy the example, substituting my IP addresses and networks etc.

Current and expected result

Should configure source based routing. Doesn't. The only interface that ever "works" is the one that has a gateway4 configured.

It is however possible to create a working configuration using netplan following the example here:

https://askubuntu.com/a/1030528

Update side navigation to new vanilla pattern

Summary

I'm trying override default gateway when using netplan DHCP without sucess

Process

Into a ubuntu 18.04.03 instance running within AWS EC2 I have this config... (netplan.io version 0.98-0ubuntu1~18.04.1)

network:
    version: 2
    ethernets:
        ens5:
            dhcp4: true
            dhcp4-overrides:
                use-routes: false
            routes:
                - to: 0.0.0.0/0
                  via: 11.0.0.254
                  metric: 0
            match:
                macaddress: 06:c1:fa:00:3d:16
            set-name: ens5

Current and expected result

After runing netplan apply I expected all routes wil be deleted and a new gateway will be added.
Instead, all routes are deleted but no gateway are added.

Summary

At the very bottom of http://netplan.io/ there are some web links. One of them, titled "Report a bug with Netplan" points to https://github.com/canonicalltd/netplan/issues/new - an unavailable location since the GitHub issue tracker is disabled (now?).

Process

• Access http://netplan.io/
• Scroll to bottom of page
• Click on "Report a bug with Netplan"

Current and expected result

The location the "Report a bug with Netplan" text link points to returns a GitHub styled 404 error.
The location it points to should present the current Netplan issue tracker.

Screenshot

(not relevant, so not included)

Summary

"Chat with netplan" links to freenode

Process

https://netplan.io/
Scroll to bottom of page and look at the "Need help" section

Current and expected result

current: freenode link
expected: liberachat link

Screenshot

Summary

The Examples page consists of lots of questions and answers of how to do various scenarios. I would like to suggestion breaking this up into two pages:

First, a How-To/FAQ page which has the current content.

Second, an examples page, which is contains real examples of specific features. For example, how to do bonding of each type, how to do a bridge, how to do vlans, etc. I have a collection of various configs that I have used for testing and I would like to have something similar on the example page.

Summary

Title says it all. As of netplan in Ubuntu 22.04 (in devel), the gateway4 and gateway6 objects are marked as deprecated now. SO, the reference doesn't reflect this.

https://netplan.io/reference/

Process

N/A

Current and expected result

Reference would mention the deprecation and link to explanations in Examples on how to set default routes instead.

Screenshot

N/A

On the site

in package.json

"@canonical/cookie-policy": "3.0.2",

in templates/partial/_footer.html

<a href="" class="js-revoke-cookie-manager">Manage your tracker settings</a>

add the js (depends on site)

static/js/base.js

import { cookiePolicy } from "@canonical/cookie-policy";
cookiePolicy();

or

<script src="/static/js/modules/cookie-policy/cookie-policy.js"></script>
<script src="/static/js/modules/global-nav/global-nav.js"></script>
<script>
  canonicalGlobalNav.createNav({
    maxWidth: '72rem',
  });
  cpNs.cookiePolicy();
</script>

add to scss

static/sass/styles.scss

// import cookie policy
@import "@canonical/cookie-policy/build/css/cookie-policy";

On the GTM

1. add variable - _cookies_accepted
2. add trigger - All pages && cookie (all or functionality) - page view regex match (all|functionality)
   3.add trigger - All pages && cookie (all or performance) - regex match (all|performance)
3. add these to the triggers based on [this sheet](https://docs.google.com/spreadsheets/d/1PQEmbJPEG-76FLtLVOO271615V5aor66UhxfomZF-lo/edit#gid=0}
4. tracker track pageview for cookie acceptance for pageview
5. trigger - custom track pageview event on event pageview

performance

• ga
• crazyegg
• usabilla
• vimeo
• google optimise

functionality

• linked in
• livechat
• facebook
• twitter
• bombora
• google adwords
• Marketo Munchkin

Summary

netplan generator creates netplan.stamp because of "Write a stamp file into the generator dir to avoid regenerating the configuration on each daemon-reload."

I am guessing daemon-reload, here means systemctl daemon-reload. However, systemd removes the generator directory, including netplan.stamp, when doing daemon-reload, and calls to regenerate all the netplan units.

which imho is the right thing to do, in case systemd-networkd is later restarted.

It leads me to believe that writing and checking for netplan.stamp file is actually pointless, throughout. And has been the case since introduction. Or is it actually in use anywhere? I.e. does any external users need it? tests or cloud-init?

Summary

According to the netplan manual page, routing-policy rules can match using the following options (when using networkd back-end): from, to, mark, type-of-service. These options map to networkd RoutingPolicyRule options: From, To, FirewallMark, TypeOfService (respectively).

There is currently no option in netplan that maps to IncomingInterface option in networkd? (This option allows traffic to match based on which interface that the packet was received on.)

There are of course many other networkd capabilities that could be added to netplan -- which would also be great -- however I believe that IncomingInterface is the most vital feature that is missing currently.

Current and expected result

Currently there is no option documented in the netplan manual page to define a rule that maps to networkd's IncomingInterface option. Might I suggest that the new option should be named "iif" (short for incoming interface), as this terminology would be consistent with the "ip rule" command's syntax and output?

Summary

https://netplan.io/design/#commands documents the following commands as existing:

• Generate
• Apply
• List
• Update
• Config

Some of those don't appear to be viable netplan commands. A "Set" and a "Show" command may also be listed; it's unclear whether they're intended to be listed as commands but weren't formatted properly during the creation of the document. They would also not be viable netplan commands.

Additionally, netplan is interpreting the commands in a case-sensitive manner (at least on Linux) and the documentation should list the working commands as all lowercase to reflect that fact.

My Ubuntu 20.04 install with netplan has the following commands available:

• help
• apply
• generate
• info
• ip
• try

Note that some of the commands in that list are missing from the command list on the netplan.io/design/#commands documentation. (The "try" command, in particular, would be helpful to propagate to new users.)

Process

View the documentation at https://netplan.io/design/#commands and compare those commands with the commands currently accepted by the software. Run "netplan" without any options to see the commands currently accepted and documented.

Current and expected result

Demonstration that the invalid commands will not work as documented (in lowercase or mixed case):

root@mojo:/etc/netplan# netplan list
usage: /usr/sbin/netplan [-h] [--debug] ...
/usr/sbin/netplan : error: argument : invalid choice: 'list' (choose from 'help', 'apply', 'generate', 'info', 'ip', 'try')

root@mojo:/etc/netplan# netplan List
usage: /usr/sbin/netplan [-h] [--debug] ...
/usr/sbin/netplan : error: argument : invalid choice: 'List' (choose from 'help', 'apply', 'generate', 'info', 'ip', 'try')

root@mojo:/etc/netplan# netplan Update
usage: /usr/sbin/netplan [-h] [--debug] ...
/usr/sbin/netplan : error: argument : invalid choice: 'Update' (choose from 'help', 'apply', 'generate', 'info', 'ip', 'try')

root@mojo:/etc/netplan# netplan update
usage: /usr/sbin/netplan [-h] [--debug] ...
/usr/sbin/netplan : error: argument : invalid choice: 'update' (choose from 'help', 'apply', 'generate', 'info', 'ip', 'try')

root@mojo:/etc/netplan# netplan Config
usage: /usr/sbin/netplan [-h] [--debug] ...
/usr/sbin/netplan : error: argument : invalid choice: 'Config' (choose from 'help', 'apply', 'generate', 'info', 'ip', 'try')

root@mojo:/etc/netplan# netplan config
usage: /usr/sbin/netplan [-h] [--debug] ...
/usr/sbin/netplan : error: argument : invalid choice: 'config' (choose from 'help', 'apply', 'generate', 'info', 'ip', 'try')

root@mojo:/etc/netplan# netplan Set
usage: /usr/sbin/netplan [-h] [--debug] ...
/usr/sbin/netplan : error: argument : invalid choice: 'Set' (choose from 'help', 'apply', 'generate', 'info', 'ip', 'try')

root@mojo:/etc/netplan# netplan set
usage: /usr/sbin/netplan [-h] [--debug] ...
/usr/sbin/netplan : error: argument : invalid choice: 'set' (choose from 'help', 'apply', 'generate', 'info', 'ip', 'try')

root@mojo:/etc/netplan# netplan Show
usage: /usr/sbin/netplan [-h] [--debug] ...
/usr/sbin/netplan : error: argument : invalid choice: 'Show' (choose from 'help', 'apply', 'generate', 'info', 'ip', 'try')

root@mojo:/etc/netplan# netplan show
usage: /usr/sbin/netplan [-h] [--debug] ...
/usr/sbin/netplan : error: argument : invalid choice: 'show' (choose from 'help', 'apply', 'generate', 'info', 'ip', 'try')

Summary

• Multistage builds to decrease image size, faster image building.
• Update .dockerignore to ignore files uncessary in prod
• Update image to Ubuntu Focal

Process

• Click the link

Current and expected result

Expect: able to file a bug

Actual: 404

currently it does not

Summary

Some visual oddities due to line-wrapping of the "code" segment.
Look at the "switchports:" section on the reference page, I see the word 'added' on the line below

Sections with wraps are:
switchports, all-wlans, bridges,

Process

View https://netplan.io/reference

Current and expected result

Some comment lines are too long and line wrap,

Screenshot

In the "Netplan configuration examples" page, "via" and "table" indentations are wrong. They should be aligned with the first letter of "to" or "from"

Summary

Bad grammar

Process

Go to "https://netplan.io/faq" and search for "Netplan configuration does not currently support hook scripts in its’ configuration definition."

Current and expected result

Current:
Netplan configuration does not currently support hook scripts in its configuration definition.

Expected:
Netplan configuration does not currently support hook scripts in its configuration definition.

["its'" should be "its" -- no apostrophe]

Screenshot

[if relevant, include a screenshot]

Summary

https://netplan.io/reference#dhcp-overrides under the section "route-metric (scalar)" states that "Use this to prioritize routes for devices by setting a higher metric on a preferred interface." Surely this should be "Use this to prioritize routes for devices by setting a lower metric on a preferred interface." as lower metrics have priority as metric is a cost?

In a previous dev catchup it was decided that our projects should be updated to use stylelint instead of sass-lint which we are currently using.

Summary

On http://netplan.io/documentation the first paragraph under "General structure" defines what 'amend' or 'override' mean for files with the same root directory but in the next sentence it jumps to files with the same name with a different root directory where it says that file "shadows" the other file. What it means for a file to be shadowed is not defined.

I would like to see 'shadows' defined to clarify behavior.

Process

1. Read the doc
2. Be a little confused

Current and expected result

The doc should make clear what it means when one config file 'shadows' another

Summary

Some files are mixed HTML and Markdown; yet some of these files are actually exact copies of information that exists elsewhere, which could be easily copied across repos to be synced, possibly automatically.

Can we please split the HTML out of the markdown, especially for reference.md, and still make it possible to sync and keep the contents separate from the functional code?

Table of contents is difficult in this case, but may be handled by generating the toc in a separate step when building/publishing the site.

Summary

I edited my netplan configuration by deleting some interfaces/bridges/vlans and then ran netplan apply, and was irked that the they were still there afterwards.

• The FAQ says:

To remove addresses manually, a user can run ip address del <address> dev <interface>.

• The man page says:

mkdir  -p  /tmp/netplan_state_backup/etc  &&  cp  -r  /etc/netplan /tmp/netplan_state_backup/etc/   

netplan      apply      –state
       /tmp/netplan_state_backup

Note: The man page shows –state, which should really be --state, since Unicode long-dashes aren't recognized by most CLI tools.

Process

1. Create an interface in a separate file in /etc/netplan
2. Run netplan apply
3. See the new interface with ip address
4. Delete the separate file in /etc/netplan
5. Run netplan apply
6. Check that the interface was deleted with ip address
7. Try the procedure in the FAQ -- meh, that looks hard
8. Try the procedure in the man page known issues section

Current and expected result

• The interface was not deleted in step 6
• Step 7 looked hard, I skipped it
• Step 8 didn't delete the interface and didn't print an error

Changing the final commands to

mkdir  -p  /tmp/netplan_state_backup/etc  &&  cp  -r  /etc/netplan /tmp/netplan_state_backup/etc/   

sudo rm /etc/netplan/interface-to-delete.yaml

sudo netplan apply --state /tmp/netplan_state_backup

worked, though.

Could you change the FAQ and man page to give the right commands?

Netplan has a bad reputation about not printing error messages and requiring a reboot to delete interfaces, this should help.

Summary

The examples on the netplan.io website use YAML indented with 2 spaces. The netplan config generated by cloud-init on machines use YAML indented with 4 spaces. So copying from netplan.io snippets to a cloud-init generated netplan file is painful.

Could we please update the netplan.io examples to use 4-spaces indentation ?

Thanks

Summary

See my title.

The problematic sentence

Using netplan gives a central location to describe simple to complex networking configurations that function from Desktop to Server and from Cloud to IoT.

An improved version of the sentence

Use hyphens, thusly:

Using netplan gives a central location to describe simple-to-complex networking configurations that function from Desktop to Server and from Cloud to IoT.

However, there are other problems with the sentence. For one thing, the capitalisation is awry.

Screenshot

Summary

I got a bug report via private email recently, which I'd like to forward to the web team:

"I am blind, and I was trying to read the netplan.io docs off your website.
Unfortunately, the body element of the page has an aria-hidden=1 attribute on the html element.
So, Orca with Firefox ignores the entire DOM when you try to access the website with a screen reader.
Norally, I'd try to find a way to report this on the website, but it's kind of hard to do since I cannot read the website at all."

Process

• Setup Orca screen reader
• Access netplan.io website

Current and expected result

A screen reader should be able to read the netplan.io website.

Summary

Link to NetworkManager goes through several redirects and looks ugly.

Process

Visit home page, click on NetworkManager

Current and expected result

Currently: end up on page with a notice referencing a redirect from WifiDocs/NetworkManager

Expected: end up straight on https://help.ubuntu.com/community/NetworkManager with no noise about redirects

Screenshot

Summary

The first bonding example is wrong

Process

Using this file :

  bonds:
    bond0:
      dhcp4: no
      interfaces:
        - eth1
      parameters:
        mode: 802.3ad
        mii-monitor-interval: 100
        transmit-hash-policy: layer3+4

Current and expected result

I expected the bond to be created, but

$ sudo netplan generate
/etc/netplan/01-netcfg.yaml:18:11: Error in network definition: bond0: interface 'eth1' is not defined
        - eth1
          ^

Summary

https://netplan.io/examples

The static ip example lacks a setting for a gateway and a dns server. Since the intention is to show an example when dhcp is not being used, these two other settings are required for a working network.

Summary

The reference page is the manpage from netplan. The page needs to be synced to grab the latest content.

Summary

• Replace Jekyll and remove its dependencies to support dotrun
• Update dockerfile and gitignore

Summary

Global nav and cookie policy are not working

Process

Go to the live website

Current and expected result

See error in the console and now cookie policy or global nav

Summary

Examples and FAQ should have a table of contents