Netplan and systemd-networkd on Debian Bookworm

Debian’s cloud-images are using systemd-networkd as their default network stack in Bookworm. A slim and feature rich networking daemon that comes included with Systemd itself. Debian’s cloud-images are deploying Netplan on top of this as an easy-to-use, declarative control layer.

If you want to experiment with systemd-networkd and Netplan on Debian, this can be done easily in QEMU using the official images. To start, you need to download the relevant .qcow2 Debian cloud-image from: https://cloud.debian.org/images/cloud/bookworm/latest/

$ wget https://cloud.debian.org/images/cloud/bookworm/latest/debian-12-generic-amd64.qcow2

Prepare a cloud image

Next, you need to prepare some configuration files for cloud-init and Netplan, to prepare a data-source (seed.img) for your local cloud-image.

$ cat > meta.yaml <<EOF
instance-id: debian01
local-hostname: cloudimg
EOF
$ cat > user.yaml <<EOF
#cloud-config
ssh_pwauth: true
password: test
chpasswd:
  expire: false
EOF
$ cat > netplan.yaml <<EOF
network:
  version: 2
  ethernets:
    id0:
      match:
        macaddress: "ca:fe:ca:fe:00:aa"
      dhcp4: true
      dhcp6: true
      set-name: lan0
EOF

Once all configuration is prepared, you can create the local data-source image, using the cloud-localds tool from the cloud-image-utils package:

$ cloud-localds --network-config=netplan.yaml seed.img user.yaml meta.yaml

Launch the local VM

Now, everything is prepared to launch a QEMU VM with two NICs and do some experimentation! The following command will launch an ephemeral environment for you, keeping the original Debian cloud-image untouched. If you want to preserve any changes on disk, you can remove the trailing -snapshot parameter.

$ qemu-system-x86_64 \
  -machine accel=kvm,type=q35 \
  -cpu host \
  -m 2G \
  -device virtio-net-pci,netdev=net0,mac=ca:fe:ca:fe:00:aa \
  -netdev user,id=net0,hostfwd=tcp::2222-:22 \
  -nic user,model=virtio-net-pci,mac=f0:0d:ca:fe:00:bb \
  -drive if=virtio,format=qcow2,file=debian-12-generic-amd64.qcow2 \
  -drive if=virtio,format=raw,file=seed.img -snapshot

We set up the default debian user account through cloud-init’s user-data configuration above, so you can now login to the system, using that user with the (very unsafe!) password “test”.

$ ssh -o "StrictHostKeyChecking=no" -o "UserKnownHostsFile=/dev/null" -p 2222 debian@localhost # password: test

Experience Netplan and systemd-networkd

Once logged in successfully, you can execute the netplan status command to check the system’s network configuration, as configured through cloud-init’s netplan.yaml passthrough. So you’ve already used Netplan at this point implicitly and it did all the configuration of systemd-networkd for you in the background!

debian@cloudimg:~$ sudo netplan status -a
     Online state: online
    DNS Addresses: 10.0.2.3 (compat)
       DNS Search: .

●  1: lo ethernet UNKNOWN/UP (unmanaged)
      MAC Address: 00:00:00:00:00:00
        Addresses: 127.0.0.1/8
                   ::1/128
           Routes: ::1 metric 256

●  2: enp0s2 ethernet DOWN (unmanaged)
      MAC Address: f0:0d:ca:fe:00:bb (Red Hat, Inc.)

●  3: lan0 ethernet UP (networkd: id0)
      MAC Address: ca:fe:ca:fe:00:aa (Red Hat, Inc.)
        Addresses: 10.0.2.15/24 (dhcp)
                   fec0::c8fe:caff:fefe:aa/64
                   fe80::c8fe:caff:fefe:aa/64 (link)
    DNS Addresses: 10.0.2.3
           Routes: default via 10.0.2.2 from 10.0.2.15 metric 100 (dhcp)
                   10.0.2.0/24 from 10.0.2.15 metric 100 (link)
                   10.0.2.2 from 10.0.2.15 metric 100 (dhcp, link)
                   10.0.2.3 from 10.0.2.15 metric 100 (dhcp, link)
                   fe80::/64 metric 256
                   fec0::/64 metric 100 (ra)
                   default via fe80::2 metric 100 (ra)

As you can see from this output, the lan0 interface is configured via the “id0” Netplan ID to be managed by systemd-networkd. Compare this data to the netplan.yaml file above, the networkctl output, the local Netplan configuration in /etc/netplan/ and the auto-generated systemd-networkd configuration.

debian@cloudimg:~$ networkctl 
IDX LINK   TYPE     OPERATIONAL SETUP     
  1 lo     loopback carrier     unmanaged
  2 enp0s2 ether    off         unmanaged
  3 lan0   ether    routable    configured

3 links listed.

debian@cloudimg:~$ cat /etc/netplan/50-cloud-init.yaml 
# [...]
network:
    ethernets:
        id0:
            dhcp4: true
            dhcp6: true
            match:
                macaddress: ca:fe:ca:fe:00:aa
            set-name: lan0
    version: 2

debian@cloudimg:~$ ls -l /run/systemd/network/
total 8
-rw-r--r-- 1 root root  78 Jul  5 15:23 10-netplan-id0.link
-rw-r--r-- 1 root root 137 Jul  5 15:23 10-netplan-id0.network

Now you can go ahead and try something more advanced, like link aggregation, using the second NIC that you configured for this QEMU VM and explore all the possibilities of Netplan on Debian, by checking the Netplan YAML documentation.

Netplan 0.106.1 stable release

We are happy to announce that Netplan 0.106.1 is available for download on Ubuntu Mantic Minotaur and Debian testing.

This release includes some improvements in our documentation and CI infrastructure and a number of bug fixes.

What’s new in Netplan 0.106.1?

Documentation

Infrastructure

  • canonical/setup-lxd GitHub action. The autopkgtest environment creation was standardized to use Canonical’s setup-lxd action.
  • Snapd integrations tests with spread. A new test set for the Snapd integration with Netplan was introduced using the spread tool.
  • DBus. A number of DBus integration tests were added to the Debian package.

New features

  • Keyfile parser improvements. Our Network Manager keyfile parser (the capability of loading Network Manager configuration to Netplan YAML) was expanded to support all the types of tunnels supported by Netplan.

Misc

  • Ubuntu’s Code of Conduct 2.0 was added to the code repository.
  • We added a new bash autocompletion script with all the Netplan’s subcommands.
  • The new release package was synchronized with Debian.

Bug fixes

  • Keyfile parser. This release contains a couple of important fixes for the NetworkManager integration stability: 1) adding WPA enterprise connections is now working fine and new test cases were added to the package; 2) a WireGuard peer with allowed IPs that don’t include the network prefix are now accepted.
  • Netplan parser. A number of memory leaks and stability issues were fixed.
  • DBus. An issue related to how directory paths are built in the Netplan DBus service was causing issues in the Snapd integration and was fixed.

For the complete list of changes please consult the debian/changelog file in https://launchpad.net/ubuntu/+source/netplan.io/+changelog

Blockchain in der Softwareentwicklung: Anwendungen jenseits von Kryptowährungen

Die Blockchain-Technologie hat in den letzten Jahren erheblichen Einfluss auf den Sektor der Softwareentwicklung genommen. Meistens kennen Sie Blockchain im Kontext von Kryptowährungen wie Bitcoin und Ethereum. Aber die Technologie bietet weit mehr Möglichkeiten als nur den Bereich der digitalen Währungen. Sie hat das Potenzial, die Art und Weise, wie wir Software entwickeln und nutzen, grundlegend zu verändern. In diesem Artikel werfen wir einen Blick auf die Anwendung von Blockchain in der Softwareentwicklung jenseits von Kryptowährungen. Wir werden die Grundlagen der Blockchain-Technologie erläutern, bevor wir auf ihre Anwendungen in verschiedenen Branchen wie dem Gesundheitswesen und dem Lieferkettenmanagement eingehen. Schließlich beleuchten wir auch die Herausforderungen und ethischen Überlegungen, die mit der Implementierung von Blockchain in der Softwareentwicklung verbunden sind. Begleiten Sie uns auf dieser spannenden Reise durch die Welt der Blockchain.

Die Grundlagen der Blockchain-Technologie: Wie sie die Softwareentwicklung revolutioniert

Um zu verstehen, wie Blockchain die Softwareentwicklung revolutioniert, sollten wir zunächst einen Blick auf die Grundlagen dieser Technologie werfen. Im Kern ist eine Blockchain eine verteilte und dezentrale Datenbank, die Informationen in digitalen Blöcken speichert. Diese Blöcke sind chronologisch und unveränderlich miteinander verknüpft, was eine hohe Sicherheit und Transparenz gewährleistet.

Microsoft Office, das weltweit führende Bürosoftwarepaket, kann als Analogie dienen. Stellen Sie sich vor, anstatt auf einer zentralen Festplatte gespeichert zu werden, würden Ihre Word-Dokumente auf mehreren Computern gleichzeitig gespeichert und ständig synchronisiert. Jede Änderung an einem Dokument würde auf allen Computern gleichzeitig erfolgen. Dies ist ein zentrales Prinzip der Blockchain-Technologie.

Die Blockchain-Technologie bringt folgende Vorteile in die Softwareentwicklung:

  • Dezentralisierung: Es gibt keinen zentralen Punkt des Versagens, was die Systeme robuster macht.
  • Transparenz: Alle Änderungen sind nachvollziehbar und transparent.
  • Sicherheit: Durch die Verschlüsselung und die Verknüpfung der Blöcke ist die Blockchain sehr sicher.

Diese Vorteile haben dazu geführt, dass die Softwareentwicklung auf eine neue Ebene gehoben wird, die über traditionelle Methoden hinausgeht.

Anwendungen von Blockchain in verschiedenen Branchen: Gesundheitswesen, Lieferkettenmanagement und mehr

Die Anwendungen der Blockchain-Technologie gehen weit über Kryptowährungen hinaus und erstrecken sich auf verschiedene Branchen. Ihre inhärente Sicherheit, Transparenz und Dezentralisierung eröffnen immense Möglichkeiten.

Im Gesundheitswesen beispielsweise können Blockchains dazu beitragen, Patientendaten sicher und transparent zu speichern. Alle medizinischen Aufzeichnungen könnten in einer Blockchain gespeichert werden, wodurch Ärzte und medizinisches Personal sofortigen Zugriff auf genaue und aktuelle Informationen hätten. Dies könnte die Patientenversorgung erheblich verbessern.

Im Bereich des Lieferkettenmanagements können Blockchains dazu beitragen, den gesamten Ablauf von der Produktion bis zur Lieferung zu verfolgen. Dies würde:

  • Transparenz für die Verbraucher schaffen, indem sie die Herkunft der Produkte nachverfolgen können.
  • Betrug und Fälschungen minimieren, da jede Änderung in der Kette sofort sichtbar ist.
  • Effizienz steigern, indem Verzögerungen und Engpässe identifiziert werden.

Die Blockchain-Technologie hat das Potenzial, die Art und Weise, wie wir Software nutzen, in vielen Bereichen zu verändern, und ihre Anwendungen nehmen ständig zu.

Die Herausforderungen und ethischen Überlegungen bei der Implementierung von Blockchain in der Softwareentwicklung

Obwohl die Blockchain-Technologie viele Vorteile bietet, gibt es auch Herausforderungen und ethische Überlegungen bei ihrer Implementierung in der Softwareentwicklung. Ein zentrales Problem ist der hohe Energieverbrauch. Da jede Transaktion auf mehreren Computern gleichzeitig verarbeitet wird, kann der Energiebedarf erheblich sein.

Ein weiterer Aspekt sind die Datenschutzbedenken. Während die Transparenz einer Blockchain viele Vorteile hat, erfordert sie auch eine sorgfältige Handhabung der Privatsphäre. Besonders in Branchen wie dem Gesundheitswesen müssen strengste Datenschutznormen eingehalten werden.

Einige der Herausforderungen und ethischen Überlegungen sind:

  • Energieverbrauch: Wie kann die Effizienz der Blockchain verbessert werden, um den Energieverbrauch zu minimieren?
  • Datenschutz: Wie können wir die Transparenz der Blockchain nutzen und gleichzeitig die Privatsphäre der Nutzer schützen?
  • Zugänglichkeit: Wie können wir sicherstellen, dass alle Menschen, unabhängig von technischem Wissen oder Ressourcen, Zugang zu den Vorteilen der Blockchain haben?

Die Auseinandersetzung mit diesen Fragen ist entscheidend für die nachhaltige Integration der Blockchain-Technologie in die Softwareentwicklung.

Innovative Materialien für PC-Gehäuse – Wie leistungsfähig sind sie wirklich?

Innovative Materialien für PC-Gehäuse sind ein wichtiger Aspekt bei der Entwicklung von leistungsfähigen und hochwertigen Computern. Die Wahl des richtigen Materials kann einen großen Einfluss auf die Kühlleistung, die Haltbarkeit und die Gesamtleistung des Systems haben. Während Metalle wie Aluminium und Stahl seit Jahrzehnten in der PC-Gehäusefertigung eingesetzt werden, gibt es heute viele neue Materialien, die eine vielversprechende Zukunft im Gehäusebau versprechen.

Die Verwendung von Kunststoffen als Gehäusematerialien hat in den letzten Jahren deutlich zugenommen, da sie leicht und kosteneffektiv sind. Metallische Verbundwerkstoffe, die aus verschiedenen Materialien wie Aluminium und Kunststoffen hergestellt werden, bieten eine höhere Steifigkeit und sind dennoch leicht und stabil. Titan und Kohlefaser werden auch immer häufiger als Gehäusematerialien eingesetzt, insbesondere in High-End-Systemen.

Trotz der vielen Vorteile, die innovative Materialien bieten können, stellt sich die Frage, wie leistungsfähig sie wirklich sind.

Der Einsatz von Kunststoffen in PC-Gehäusen – Robust und kosteneffizient?

Der Einsatz von Kunststoffgehäusen bei PCs hat in den letzten Jahren stark zugenommen. Kunststoffe bieten viele Vorteile wie beispielsweise Leichtigkeit, Wärmeisolierung und Schallabsorption. Im Vergleich zu herkömmlichen Materialien wie Aluminium oder Stahl sind Kunststoffe auch kosteneffizienter in der Herstellung.

Ein weiterer Vorteil von einem Kunststoffgehäuse ist seine hohe Robustheit. Moderne Kunststoffe wie Polycarbonat und ABS sind sehr widerstandsfähig und bieten Schutz vor äußeren Einflüssen wie Stößen, Kratzern oder Feuchtigkeit. Darüber hinaus sind Kunststoffe auch sehr anpassungsfähig in Bezug auf Form und Farbe. Dies gibt Designern und Herstellern viel Freiheit, um kreative und individuelle Gehäuse-Designs zu entwickeln.

Allerdings gibt es auch einige Herausforderungen beim Einsatz von Kunststoffen in PC-Gehäusen. Zum Beispiel neigen Kunststoffe dazu, sich bei hoher Belastung oder Temperaturen zu verziehen. Dies kann zu unerwünschten Verzerrungen und Rissen im Gehäuse führen. Um diesen Herausforderungen entgegenzuwirken, verwenden einige Hersteller spezielle Materialien und Fertigungstechniken, um die Haltbarkeit und Leistungsfähigkeit von Kunststoff-Gehäusen zu erhöhen.

Metallische Verbundwerkstoffe – Die Zukunft des Gehäusebaus?

Metallische Verbundwerkstoffe sind eine vielversprechende neue Klasse von Materialien, die im Gehäusebau eingesetzt werden können. Sie bestehen aus einer Kombination von Metallen und Polymeren und bieten eine höhere Steifigkeit und Stärke im Vergleich zu herkömmlichen Kunststoffen. Sie sind auch leichter und stabiler als reine Metalle wie Aluminium und Stahl, was bedeutet, dass sie eine bessere Leistung und Haltbarkeit bieten können.

Metallische Verbundwerkstoffe bieten auch eine höhere Wärmeleitfähigkeit als Kunststoffe, was sie zu einer idealen Wahl für Gehäuse macht, die eine hohe Kühlleistung erfordern. Sie bieten auch eine hohe chemische Beständigkeit und sind resistent gegenüber äußeren Einflüssen wie Feuchtigkeit, Stößen und Kratzern. Dadurch sind sie ideal für den Einsatz in rauen Umgebungen oder für den Transport von Systemen geeignet.

Trotz dieser Vorteile gibt es auch Herausforderungen beim Einsatz von metallischen Verbundwerkstoffen im Gehäusebau. Zum Beispiel sind sie oft teurer in der Herstellung als Kunststoffe und erfordern spezielle Fertigungstechniken. Darüber hinaus können sie in einigen Fällen anfälliger für Korrosion und Oxidation sein.

Ein Vergleich von Aluminium und Titan als Materialien für High-End-PC-Gehäuse

Bei der Wahl von Materialien für High-End-PC-Gehäuse sind Aluminium und Titan zwei der am häufigsten verwendeten Optionen. Beide Materialien bieten eine hohe Leistung und sind langlebig, aber es gibt einige Unterschiede, die bei der Auswahl berücksichtigt werden sollten.

Aluminium ist ein leichtes und dennoch robustes Material, das seit Jahren in der Gehäusefertigung eingesetzt wird. Es ist kosteneffektiver als Titan und bietet eine hohe Wärmeableitung, was es ideal für den Einsatz in leistungsfähigen Systemen macht. Aluminium ist auch leichter zu bearbeiten als Titan und kann in einer Vielzahl von Farben und Texturen hergestellt werden.

Titan ist jedoch noch widerstandsfähiger und leichter als Aluminium und bietet eine höhere Korrosionsbeständigkeit. Es ist auch teurer als Aluminium und erfordert spezielle Fertigungstechniken. Titan-Gehäuse haben oft eine polierte Oberfläche und sind in der Regel nur in begrenzten Farben erhältlich.

Containerisierung und Agile Softwareentwicklung: Potentiale, Hindernisse und bewährte Methoden

Die Agile Softwareentwicklung hat die Art und Weise, wie wir Software erstellen und bereitstellen, revolutioniert, indem sie iterative Entwicklungszyklen und eine ständige Feedback-Schleife fördert. Parallel dazu hat die Einführung der Containerisierungstechnologie das Spielfeld verändert und bietet eine Reihe von Vorteilen, die sich hervorragend in das agile Paradigma einfügen.

Chancen der Containerisierung für die Agile Softwareentwicklung

Die Containerisierung hat sich als ein enormer Katalysator für die Agile Softwareentwicklung erwiesen. Sie ermöglicht eine schnelle und flexible Bereitstellung von Anwendungen, indem sie eine isolierte Umgebung bereitstellt, in der Anwendungen unabhängig von der zugrunde liegenden Infrastruktur ausgeführt werden können. Dieser Ansatz unterstützt eine effizientere Nutzung von Ressourcen, fördert die Zusammenarbeit und Integration von Entwicklungs- und Betriebsteams und reduziert die Abhängigkeit von spezifischen Betriebssystemen oder Umgebungen.

Die Containerisierung unterstützt auch die Skalierung und Resilienz von Anwendungen. Durch die Nutzung von Container-Orchestrierungsplattformen wie Kubernetes können Teams Anwendungen schnell und nahtlos auf eine größere Anzahl von Servern oder sogar über verschiedene Cloud-Umgebungen hinweg skalieren. Darüber hinaus erhöht die Fähigkeit von Containern, bei Ausfällen schnell neu zu starten, die Gesamtresilienz des Systems.

Herausforderungen bei der Containerisierung von Anwendungen in der Agile Softwareentwicklung

Trotz der vielfältigen Vorteile stellt die Containerisierung auch eine Reihe von Herausforderungen dar. Eine davon ist die erhöhte Komplexität bei der Verwaltung von Container-Orchestrierung und -Deployment. Kubernetes, eine führende Plattform in diesem Bereich, hat zwar eine beeindruckende Funktionalität, aber auch eine steile Lernkurve und kann komplex in der Handhabung sein.

Die Integration von Container-Plattformen in bestehende Tools und Prozesse kann ebenfalls schwierig sein. Viele traditionelle Entwicklungs- und Bereitstellungstools sind nicht darauf ausgelegt, mit Containern zu arbeiten, und erfordern Anpassungen oder sogar vollständige Überarbeitungen, um effektiv genutzt werden zu können.

Darüber hinaus birgt die Containerisierung potenzielle Sicherheitsrisiken. Containeranwendungen eröffnen neue Angriffsvektoren, und die Fehlkonfiguration von Containern kann zu erheblichen Sicherheitsproblemen führen. Zudem besteht eine Abhängigkeit von der Verfügbarkeit und Stabilität der zugrunde liegenden Infrastruktur, was ein zusätzliches Risiko darstellen kann.

Best Practices für die Verwendung von Containern in der Agile Softwareentwicklung

Trotz dieser Herausforderungen gibt es eine Reihe von bewährten Methoden, die Unternehmen dabei unterstützen können, das Potenzial der Containerisierung voll auszuschöpfen. Dazu gehört das Etablieren von klaren Entwicklungs- und Bereitstellungsprozessen für Containeranwendungen. Diese Prozesse sollten den gesamten Lebenszyklus des Containers abdecken, von der Entwicklung und dem Testing über die Bereitstellung bis hin zum Monitoring und zur Wartung.

Ein weiterer wichtiger Aspekt ist die Automatisierung von Build-, Test- und Bereitstellungsprozessen. Tools wie Jenkins, GitLab CI/CD und Spinnaker können hierbei helfen, die Effizienz zu steigern und menschliche Fehler zu minimieren. Insbesondere in Kombination mit Container-Orchestrierungstools wie Kubernetes kann dies zu einer erheblichen Beschleunigung der Entwicklung und Bereitstellung führen.

In Bezug auf Sicherheitsaspekte sollten Unternehmen robuste Zugriffskontrollen implementieren und Verschlüsselung sowohl für Daten in Ruhe als auch für Daten während der Übertragung einsetzen. Tools zur Erkennung von Sicherheitslücken, wie z.B. Aqua Security und Twistlock, können kontinuierliche Scans von Containerbildern durchführen, um bekannte Schwachstellen zu identifizieren und zu beheben.

Schließlich ist die Überwachung und Protokollierung von Containeranwendungen in Echtzeit von entscheidender Bedeutung. Tools wie Prometheus und Grafana bieten wertvolle Einblicke in die Leistung und den Zustand von Containeranwendungen und ermöglichen es Teams, Probleme schnell zu erkennen und zu beheben.

Netplan v0.106 is now available

I’m happy to announce that Netplan version 0.106 is now available on GitHub and is soon to be deployed into an Ubuntu/Debian/Fedora installation near you! Six months and 65 commits after the previous version, this release is brought to you by 4 free software contributors from around the globe.

Highlights

Highlights of this release include the new netplan status command, which queries your system for IP addresses, routes, DNS information, etc… in addition to the Netplan backend renderer (NetworkManager/networkd) in use and the relevant Netplan YAML configuration ID. It displays all this in a nicely formatted way (or alternatively in machine readable YAML/JSON format).

Furthermore, we implemented a clean libnetplan API which can be used by external tools to parse Netplan configuration, migrated away from non-inclusive language (PR#303) and improved the overall Netplan documentation. Another change that should be noted, is that the match.macaddress stanza now only matches on PermanentMACAddress= on the systemd-networkd backend, as has been the case on the NetworkManager backend ever since (see PR#278 for background information on this slight change in behavior).

Changelog

Bug fixes:

Netplan v0.105 is now available

I’m happy to announce that Netplan version 0.105 is now available on GitHub and is soon to be deployed into an Ubuntu/Debian installation near you! Six month and exactly 100 commits after the previous version, this release is brought to you by 7 free software contributors from around the globe.

Changelog

  • Add support for VXLAN tunnels (#288), LP#1764716
  • Add support for VRF devices (#285), LP#1773522
  • Add support for InfiniBand (IPoIB) (#283), LP#1848471
  • Allow key configuration for GRE tunnels (#274), LP#1966476
  • Allow setting the regulatory domain (#281), LP#1951586
  • Documentation improvements & restructuring (#287)
  • Add meson build system (#268)
  • Add abigail ABI compatibility checker (#269)
  • Update of Fedora RPM spec (#264)
  • CI improvements (#265#282)
  • Netplan set uses the consolidated libnetplan YAML parser (#254)
  • Refactor ConfigManager to use the libnetplan YAML parser (#255)
  • New netplan_netdef_get_filepath API (#275)
  • Improve NetworkManager device management logic (#276), LP#1951653

Bug fixes

Netplan v0.104 is now available

I’m happy to announce that netplan.io version 0.104 is now available on Github and has been uploaded into the next Ubuntu LTS release, code name “Jammy”: netplan.io 0.104-0ubuntu1! This is a big release that has been brought to you by 10 contributors around the globe.

Changelog:

  • Enable embedded-switch-mode setting on SmartNICs (#253)
  • Permit multiple patterns for the driver globs in match (#202), LP#1918421
  • Improve routing capabilities (#248), LP#1892272LP#1805038
  • Support additional link offload options for networkd (#225) (#242), LP#1771740
    • receive-checksum-offloadtransmit-checksum-offloadtcp-segmentation-offload,
      tcp6-segmentation-offloadgeneric-segmentation-offloadgeneric-receive-offload,
      large-receive-offload
  • Consolidate enum-to-string arrays (#230)
  • Handle differing ip6-privacy default value for NetworkManager (#263)
  • YAML state tracking (--state rootdir) for DBus API and netplan try (#231), LP#1943120
  • Support ConfigureWithoutCarrier (ignore-carrier) for networkd (#215)
  • Move primary git branch master to main
  • Documentation improvements (#226)
  • Compatibility for glib-2.70 (#235)
  • Cleanup Makefile, install only public headers
  • Improve test reliability & enable integration testing CI for autopkgtests
  • Netplan get to use the libnetplan parser (#252)
  • libnetplan:
    • introduce the notion of NetplanState (#232)
    • use an explicit parser context (#233)
    • expose coherent generator APIs (#239)
    • improve overall error handling (#234)
    • consolidation of YAML parsing into the library (#241#249#250#251)
  • Restrict the symbol export to a determined public API (#227)
    • WARNING: We dropped some internal symbols from the API that we know
      have no external consumers (that we are aware of)
    • 0.103: _serialize_yamlcontains_netdef_typetmpvalidate_default_route_consistency
    • 0.102: cur_filenamenetplan_netdef_new
    • 0.100: address_option_handlersis_hostnamevalidate_ovs_targetwireguard_peer_handlers
    • 0.99: current_fileis_ip4_addressis_ip6_addressmissing_id,
      missing_ids_foundparser_errorvalidate_backend_rulesvalidate_netdef_grammar,
      yaml_error

Bug fixes:

  • Fix removal of defunct OVS vlan interfaces (#256), LP#1959147
  • Make ConfigManager cleanup on destruction (#259), LP#1959729
  • Do not write unvalidated YAML from keyfile (#247), LP#1952967
  • Disable temporary address generation for real with NetworkManager (#244), LP#1948027
    • this is a slight change in behavior for NM, but is in line with the docs
      and implementation of the networkd backend renderer
  • Ignore empty YAML hints and delete files on set network=null (#246), LP#1946957
  • Wait for ‘netplan try’ to be ready in DBus API (#245), LP#1949893
  • Initialize self.state in apply (#243), LP#1949104
  • Driver fallback to nl80211 and/or wext for wpa_supplicant (#240), LP#1814012
  • Handle missing gateway in keyfile routes, keep dns-search fallback (#238)
  • Make it possible to unset a whole devtype subtree (#236), LP#1942930
  • Fix normalization of multiple keys on a single dict in tests (#229)
  • Add default-routes feature flag
  • Fix memory leaks, dangling pointers & overall cleanup of API data (#228)
  • Small whitespace and formatting fixes & shipping EditorConfig (#224)

Simple EOS Dev Environment

This is a beginner’s guide, to setup a simple development environment for the EOSIO blockchain, which will get you up and running in five simple steps from zero to your first smart contract in less than 10 minutes. Afterwards, you will know how to code and test your own smart contracts on an EOS testnet quickly and for free. In this guide we make use of simple tools, which offer a great developer experience, such as the eosio.cdt (Contract Development Toolkit), the Kylin testnet and the eosc command line wallet. We’re using a development machine, running the Ubuntu 18.04 operating system.

So let’s get started!

1. Account, Keys and Tokens

The Kylin Testnet, which is run by several high class block producers, allows easy and fast access to a (non-productive) EOSIO blockchain, using it’s free Account and Faucet services. We’re going to create a new EOS account (12 character name) on the testnet, including @owner and @active keypairs and charge it up with 100 dummy EOS tokens.

Let’s call our new EOS account: dummyaccount

curl http://faucet.cryptokylin.io/create_account?dummyaccount

{
  "msg": "succeeded",
  "keys": {
    "active_key": {
      "public": "EOS7kNBssiunoW7VGcx79BXGUvjbgcaPva4azRwhuTXRfJJ192DJ2",
      "private": "5J1SYvRP1JpWBtk85a4zAbXUmAyBqtr3r58hLuDF5YX6HdcfTYo"
    },
    "owner_key": {
      "public": "EOS6nUXrdodNwRspd7Z42Yp8nRH44wuJNYYoVHSMddr28KKS6Ke4J",
      "private": "5KQzVMR9sZ8sRmRb3NQEzyW43peUow6pYLo831AAXGyEZP7h77z"
    }
  },
  "account": "dummyaccount"
}

curl http://faucet.cryptokylin.io/get_token?dummyaccount

{ "msg": "succeeded" }

Save your @owner and @active keypairs somewhere safe, you’ll need them for the next steps.

2. Wallet and CLI

Next we will download and install the eosc command line wallet, by EOS Canada, in order to interact with the EOS blockchain (currently v1.1.0). This will help us to safely store our private keys and send transactions to the blockchain.

mkdir eosc && cd eosc
curl -LO https://github.com/eoscanada/eosc/releases/download/v1.1.0/eosc_1.1.0_linux_x86_64.tar.gz
tar xzvf ./eosc_1.1.0_linux_x86_64.tar.gz

Now we can use it to import our EOS account via the @active key. This will create a file, named eosc-vault.json, which will contain your encrypted private key.

./eosc vault create --import

- Paste your @active private key from above.
  5J1SYvRP1JpWBtk85a4zAbXUmAyBqtr3r58hLuDF5YX6HdcfTYo
- Hit ENTER.
- Choose a passphrase

3. Account Setup

Here we will issue three ./eosc commands, to setup our account for the deployment of a smart contract. We delegate 20 EOS tokens as blockchain resources (5 EOS staked for NET, 15 EOS staked for CPU) and use some more EOS tokens to buy 500 KiB of RAM as storage for our smart contract. Finally, we check our account with the eosc get account command.

Hint: We need approximately 10x the bytes of RAM as is the filesize of our WASM binary contract, due to the overhead of the virtual machine. So if our compiled contract file (e.g. hello.wasm) has a filesize of 10 KiB, we need approximately 100 KiB in RAM resources on the EOSIO blockchain, to deploy the contract.

./eosc -u https://kylin.eoscanada.com system delegatebw dummyaccount dummyaccount 5 15

./eosc -u https://kylin.eoscanada.com system buyrambytes dummyaccount dummyaccount 512000

./eosc -u https://kylin.eoscanada.com get account dummyaccount
privileged:   false
created at:   2018-11-15 14:45:25 +0000 UTC

permissions:
     "owner" w/1         :  +1 EOS6nUXrdodNwRspd7Z42Yp8nRH44wuJNYYoVHSMddr28KKS6Ke4J
           "active" w/1  :  +1 EOS7kNBssiunoW7VGcx79BXGUvjbgcaPva4azRwhuTXRfJJ192DJ2

memory:
      quota:           506.8  KB   used:           3.490  KB

net bandwidth:
      staked:              5.0000  EOS    (total stake delegated from account to self)
      delegated:           1.0000  EOS    (total stake delegated to account from others)
      used:                   257  bytes
      available:            11.18  MB
      limit:                11.18  MB

cpu bandwidth:
      staked:             15.0000  EOS  (total stake delegated from account to self)
      delegated:           1.0000  EOS  (total stake delegated to account from others)
      used:                 1.129  ms
      available:            807.2  ms
      limit:                808.3  ms

EOS balances:
      liquid:             67.8553  EOS
      staked:             20.0000  EOS
      unstaking:           0.0000  EOS
      total:              87.8553  EOS

voted for:
      

voter info:
      proxy:                
      is proxy:             false
      staked:               200000
      vote weight:          0.000000
      proxied vote weight:  0.000000

4. Contract Development Toolkit

Download and install the latest version of eosio.cdt (currently v1.4.1). This will give you access to the smart contract WASM and ABI compilers/generators, as well as to the eosio C/C++ libraries and header files. Get it at: https://github.com/EOSIO/eosio.cdt/releases

curl -LO https://github.com/EOSIO/eosio.cdt/releases/download/v1.4.1/eosio.cdt-1.4.1.x86_64.deb
sudo dpkg -i ./eosio.cdt-1.4.1.x86_64.deb

5. Compile and Deploy a Smart Contract

Let’s create a simple “Hello World” smart contract, by creating a file with the following contents, named hello.cpp:

#include <eosiolib/eosio.hpp>
#include <eosiolib/print.hpp>

using namespace eosio;

CONTRACT hello : public contract {
  public:
      using contract::contract;

      ACTION hi( name user ) {
         print( "Hello, ", name{user});
      }

      ACTION yo( name user ) {
         print( "Yo, ", name{user});
      }
};
EOSIO_DISPATCH( hello, (hi)(yo) )

This C++ file can now be compiled and deployed to the EOS blockchain, using the eosio.cdt Contract Development Toolkit. After compilation we will get a binary WASM file hello.wasm of about 2.3 KiB (needs ~23 KiB of eosio RAM) and a file named hello.abi, which describes the interface of our code’s actions.

eosio-cpp -o hello.wasm hello.cpp --abigen

./eosc -u https://kylin.eoscanada.com system setcontract dummyaccount ./hello.wasm ./hello.abi

./eosc -u https://kylin.eoscanada.com tx create dummyaccount yo '{"user":"bob"}' -p dummyaccount

Congratulations!

After finishing the five simple steps above, you can now officially call yourself a “Blockchain Expert”. 😉

Feel free to experiment with the above mentioned tools, keep on improving your EOSIO knowledge with help of the hyperlinks I put into the article and continue to develop you very own EOS smart contracts!

If you liked this tutorial, please consider a donation to my EOS account: teammaerdian