Netplan v0.107 is now available

by

I’m happy to announce that Netplan version 0.107 is now available on GitHub and is soon to be deployed into a Linux installation near you! Six months and more than 200 commits after the previous version (including a .1 stable release), this release is brought to you by 8 free software contributors from around the globe.

Highlights

Highlights of this release include the new configuration types for veth and dummy interfaces:

network:
  version: 2
  virtual-ethernets:
    veth0:
      peer: veth1
    veth1:
      peer: veth0
  dummy-devices:
    dm0:
      addresses:
        - 192.168.0.123/24
      ...

Furthermore, we implemented CFFI based Python bindings on top of libnetplan’s API, that can easily be consumed by 3rd party applications (see full cffi-bindings.py example):

from netplan import Parser, State, NetDefinition
from netplan import NetplanException, NetplanParserException

parser = Parser()

# Parse the full, existing YAML config hierarchy
parser.load_yaml_hierarchy(rootdir='/')

# Validate the final parser state
state = State()
try:
    # validation of current state + new settings
    state.import_parser_results(parser)
except NetplanParserException as e:
    print('Error in', e.filename, 'Row/Col', e.line, e.column, '->', e.message)
except NetplanException as e:
    print('Error:', e.message)

# Walk through ethernet NetdefIDs in the state and print their backend
# renderer, to demonstrate working with NetDefinitionIterator &
# NetDefinition
for netdef in state.ethernets.values():
    print('Netdef', netdef.id, 'is managed by:', netdef.backend)
    print('Is it configured to use DHCP?', netdef.dhcp4 or netdef.dhcp6)

Changelog:

Bug fixes:

A declarative approach to Linux networking with Netplan

by
Photo by Taylor Vick (Unsplash)

Linux networking can be confusing due to the wide range of technology stacks and tools in use, in addition to the complexity of the surrounding network environment. The configuration of bridges, bonds, VRFs or routes can be done programmatically, declaratively, manually or with automated with tools like ifupdown, ifupdown2, ifupdown-ng, iproute2, NetworkManager, systemd-networkd and others. Each  of these tools use different formats and locations to store their configuration files. Netplan, a utility for easily configuring networking on a Linux system, is designed to unify and standardise how administrators interact with these underlying technologies. Starting from a YAML description of the required network interfaces and what each should be configured to do, Netplan will generate all the necessary configuration for your chosen tool.

In this article, we will provide an overview of how Ubuntu uses Netplan to manage Linux networking in a unified way. By creating a common interface across two disparate technology stacks, IT administrators benefit from a unified experience across both desktops and servers whilst retaining the unique advantages of the underlying tech.

But first, let’s start with a bit of history and show where we are today.

The history of Netplan in Ubuntu

Starting with Ubuntu 16.10 and driven by the need to express network configuration in a common way across cloud metadata and other installer systems, we had the opportunity to switch to a network stack that integrates better with our dependency-based boot model. We chose systemd-networkd on server installations for its active upstream community and because it was already part of Systemd and therefore included in any Ubuntu base installation. It has a much better outlook for the future, using modern development techniques, good test coverage and CI integration, compared to the ifupdown tool we used previously. On desktop installations, we kept using NetworkManager due to its very good integration with the user interface.

Having to manage and configure two separate network stacks, depending on the Ubuntu variant in use, can be confusing, and we wanted to provide a streamlined user experience across any flavour of Ubuntu. Therefore, we introduced Netplan.io as a control layer above systemd-networkd and NetworkManager. Netplan takes declarative YAML files from /etc/netplan/ as an input and generates corresponding network configuration for the relevant network stack backend in /run/systemd/network/ or /run/NetworkManager/ depending on the system configuration. All while keeping full flexibility to control the underlying network stack in its native way if need be.

Design overview (netplan.io)

Who is using Netplan?

Recent versions of Netplan are available and ready to be installed on many distributions, such as Ubuntu, Fedora, RedHat Enterprise Linux, Debian and Arch Linux.

Ubuntu

As stated above, Netplan has been installed by default on Ubuntu systems since 2016 and is therefore being used by millions of users across multiple long-term support versions of Ubuntu (18.04, 20.04, 22.04) on a day-to-day basis. This covers Ubuntu server scenarios primarily, such as bridges, bonding, VLANs, VXLANs, VRFs, IP tunnels or WireGuard tunnels, using systemd-networkd as the backend renderer.

On Ubuntu desktop systems, Netplan can be used manually through its declarative YAML configuration files, and it will handle those to configure the NetworkManager stack. Keep reading to get a glimpse of how this will be improved through automation and integration with the desktop stack in the future.

Cloud

It might not be as obvious, but many people have been using Netplan without knowing about it when configuring a public cloud instance on AWS, Google Cloud or elsewhere through cloud-init. This is because cloud-init’s “Networking Config Version 2” is a passthrough configuration to Netplan, which will then set up the underlying network stack on the given cloud instance. This is why Netplan is also a key package on the Debian distribution, for example, as it’s being used by default on Debian cloud images, too.

Our vision for Linux networking

We know that Linux networking can be a beast, and we want to keep simple things simple. But also allow for custom setups of any complexity. With Netplan, the day-to-day networking needs are covered through easily comprehensible and nicely documented YAML files, that describe the desired state of the local network interfaces, which will be rendered into corresponding configuration files for the relevant network stack and applied at (re-)boot or at runtime, using the “netplan apply” CLI. For example /etc/netplan/lan.yaml:

network:
  version: 2
  renderer: networkd
  ethernets:
    enp3s0:
      dhcp4: true

Having a single source of truth for network configuration is also important for administrators, so they do not need to understand multiple network stacks, but can rely on the declarative data given in /etc/netplan/ to configure a system, independent of the underlying network configuration backend. This is also very helpful to seed the initial network configuration for new Linux installations, for example through installation systems such as Subiquity, Ubuntu’s desktop installer or cloud-init across the public and private clouds.

In addition to describing and applying network configuration, the “netplan status” CLI can be used to query relevant data from the underlying network stack(s), such as systemd-networkd, NetworkManager or iproute2, and present them in a unified way.

Netplan status (Debian)

At the Netplan project we strive for very high test automation and coverage with plenty of unit tests, integration tests and linting steps, across multiple Linux distros, which gives high confidence in also supporting more advanced networking use cases, such as Open vSwitch or SR-IOV network virtualization, in addition to normal wired (static IP, DHCP, routing), wireless (e.g. wwan modems, WPA2/3 connections, WiFi hotspot, controlling the regulatory domain, …) and common server scenarios.

Should there ever be a scenario that is not covered by Netplan natively, it allows for full flexibility to control the underlying network stack directly through systemd override configurations or NetworkManager passthrough settings in addition to having manual configuration side-by-side with interfaces controlled through Netplan.

The future of Netplan desktop integration

On workstations, the most common scenario is for end users to configure NetworkManager through its user interface tools, instead of driving it through Netplan’s declarative YAML files, which makes use of NetworkManager’s native configuration files. To avoid Netplan just handing over control to NetworkManager on such systems, we’re working on a bidirectional integration between NetworkManager and Netplan to further improve the “single source of truth” use case on Ubuntu desktop installations.

Netplan is shipping a “libnetplan” library that provides an API to access Netplan’s parser and validation internals, that can be used by NetworkManager to write back a network interface configuration. For instance, configuration given through NetworkManager’s UI tools or D-Bus API can be exported to Netplan’s native YAML format in the common location at /etc/netplan/. This way, administrators just need to care about Netplan when managing a fleet of Desktop installations. This solution is currently being used in more confined environments, like Ubuntu Core, when using the NetworkManager snap, and we will deliver it to generic Ubuntu desktop systems in 24.04 LTS.

In addition to NetworkManager, libnetplan can also be used to integrate with other tools in the networking space, such as cloud-init for improved validation of user data or installation systems when seeding new Linux images.

Conclusion

Overall, Netplan can be considered to be a good citizen within a network environment that plays hand-in-hand with other networking tools and makes it easy to control modern network stacks, such as systemd-networkd or NetworkManager in a common, streamlined and declarative way. It provides a “single source of truth” to network administrators about the network state, while keeping simple things simple, but allowing for arbitrarily complex custom setups.
If you want to learn more, feel free to follow our activities on Netplan.io, GitHub, Launchpad, IRC or our Netplan Developer Diaries blog on discourse.

Netplan and systemd-networkd on Debian Bookworm

by

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

by

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

Netplan v0.106 is now available

by

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

by

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

by

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#1892272, LP#1805038
  • Support additional link offload options for networkd (#225) (#242), LP#1771740
    • receive-checksum-offload, transmit-checksum-offload, tcp-segmentation-offload,
      tcp6-segmentation-offload, generic-segmentation-offload, generic-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_yaml, contains_netdef_type, tmp, validate_default_route_consistency
    • 0.102: cur_filename, netplan_netdef_new
    • 0.100: address_option_handlers, is_hostname, validate_ovs_target, wireguard_peer_handlers
    • 0.99: current_file, is_ip4_address, is_ip6_address, missing_id,
      missing_ids_found, parser_error, validate_backend_rules, validate_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

by

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

Freifunk mit Ubiquiti UniFi AP

by

Freifunk.net

Inhalt

Was ist Freifunk.net?

Die Initiative Freifunk.net ist ein nicht-komerzielles, gemeinschaftliches Projekt vieler Freiwilliger, die sich zum Ziel gesetzt haben ein unabhängiges und dezentrales WLAN-Netzwerk aufzubauen, welches von Jederman frei zugänglich, unzensiert und anonym verwendet werden kann und außerdem die Netzneutralität wahrt. Die Initiative ist dabei in lokalen Freifunk-Communities organisiert, welche in jeder größeren und kleineren Stadt anzutreffen sind.

Das Freifunk-Netz erstreckt sich bereits über ganz Deutschland und wächst mit jedem Unterstützer ein Stückchen weiter. Ob auch in deiner Nähe schon ein Freifunk-Zugangspunkt ist, über den du ohne Anmeldung einen freien Internet-Zugang bekommen kannst, erfährst du auf der Freifunk-Karte!

Mitmachen darf jeder! Zum Unterstützen der Idee tritt man am besten mit seiner lokalen Freifunk-Community in Kontakt. Dort kann man sich informieren und austauschen und im Regelfall auch einen eigenen, vorkonfigurierten Freifunk-Router ab 20€ beziehen. Schau also einfach vorbei, z.B. bei Freifunk-München!

Freifunk verbindet!

Freifunk Technik

Freifunk ist als Mesh-Netzwerk konzipiert. Das bedeutet, dass sich benachbarte Freifunk-Router (Knoten) automatisch miteinander verbinden. Netzwerk-Pakete werden dann auf ihrem Weg vom Benutzer (z.B. Smartphone) von Knoten zu Knoten weitergeleitet bis sie ihr Ziel (z.B. Wikipedia) erreichen. Um auch in Situationen in denen keine benachbarten Freifunk-Knoten in Reichweite sind einen Zugang zum Freifunk-Netz zu bekommen, betreiben die Freifunk Communities VPN-Gateways. Isolierte Knoten können so über den privaten Internetzugang des Knoten-Betreibers eine verschlüsselte VPN-Verbindung zum restlichen Freifunk-Netz herstellen. Vom VPN-Gateway aus kann – über eine Verbindung ins Ausland – auch das Internet erreicht werden. Auf diese Weise wird geschickt das rechtliche Problem der deutschen Störerhaftung umgangen.

Auf Freifunk-Routern läuft eine speziell angepasste Version der freien OpenWrt Firmware, namens Gluon. Gluon stellt dabei eine stark vereinfachte Web-Oberfläche bereit, welche zum Einrichten und Konfigurieren eines Freifunk-Knotens verwendet werden kann. Außerdem enthält Gluon einen Autoupdater, welcher den eigenen Freifunk-Knoten immer automatisch auf den aktuellen Softwarestand updatet. Für erfahrene Benutzer gibt es zusätzlich die Möglichkeit sich per SSH auf dem Router einzuloggen, um den vollen Funktionsumfang von OpenWrt auszunutzen.

Unterstützte Hardware

Durch die OpenWrt Basis der Freifunk Firmware “Gluon” gibt es eine breite Auswahl an unterstützen Routern. Zu den geläufigsten Modellen zählen Router der Firmen TP-Link und Ubiquiti Networks. Welche Router im einzelnen unterstützt werden erfährt man auf der Website der lokalen Freifunk-Community. Wegen eines sehr guten Preis-Leistungs-Verhältnisses (Preis < 20€) erfreut sich der Router “TP-Link TL-WR841N” zur Zeit sehr großer Beliebtheit.

Ubnt UniFi APIch habe mich für meinen ersten Freifunk-Knoten für das Modell “Ubiquiti UniFi AP Long Range” (Ubnt UAP-LR) entschieden. Dieser bietet eine sehr gute Reichweite von bis zu 180m, eine leichte Verkabelung dank Stromversorgung über das Netzwerkkabel und wird offiziell von meiner Freifunk-Community (Freifunk-München) unterstützt. Die Freifunk Installation und Konfiguration dieses Routers möchte ich im folgenden exemplarisch für “Freifunk-München” erläutern.

UniFi Router flashen

Nach dem Auspacken und Anschließen des UniFi AP ans lokale Heim-Netzwerk bekommt dieser per DHCP automatisch eine IP-Adresse zugewiesen (<UAP-IP>), welche in der Web-Oberfläche des privaten Internet-Routers (z.B. FritzBox) nachgeschaut werden kann. Mit einem Linux-Computer erfolgt die Installation der Freifunk Firmware (Gluon) auf dem UniFi AP danach in 3 einfachen Schritten:

  1. Via SSH in die original Software des UAP einloggen: 
    ssh ubnt@<UAP-IP> #(Passwort: ubnt)
  2. UniFi Factory-Firmware der lokalen Freifunk-Community ins /tmp Verzeichnis des Routers downloaden, z.B.: 
    cd /tmp
wget http://firmware.ffmuc.net/stable/factory/gluon-ffmuc-v2015.2-ubiquiti-unifi.bin
  3. Freifunk-Firmware auf den Router flashen: 
    fwupdate.real -m gluon-ffmuc-v2015.2-ubiquiti-unifi.bin -d

Nachdem das Kommando ‘fwupdate.real’ erfolgreich ausgeführt wurde, gibt es das Wort “Done” aus und der Router kann vom Strom-/Netzwerkkabel und vom Heim-Netzwerk (am PoE-Adapter) getrennt werden. (Quelle)

UniFi Router konfigurieren

Anstelle vom Heim-Netzwerk (z.B. FritzBox) sollte der Router jetzt direkt mit dem eigenen Computer verbunden werden. Nachdem das Strom-/Netzwerkkabel wieder angesteckt wurde startet der UniFi AP die neu installierte Freifunk-Firmware im Setup/Config-Mode. Alternativ erreicht man den Config-Mode durch drücken der Reset-Taste für ca. 3 Sekunden. Den Config-Mode kann man daran erkennen, dass die grüne LED des Routers blinkt (ca. 1x pro Sekunde).

Gluon Web UIIm Config-Mode hat der UAP die IP-Adresse 192.168.1.1 und betreibt einen DHCP-Server, so dass der eigene Computer automatisch eine IP-Adresse aus dem Bereich 192.168.1.x/24 zugewiesen bekommen sollte. Alternativ kann dem eigenen Computer auch manuell eine IP-Adresse aus diesem Bereich gegeben werden (z.B. 192.168.1.100). Steht die Verbindung zwischen Computer und Router, kann die Gluon Web-Oberfläche auf http://192.168.1.1 erreicht werden.

Die Gluon Web-Oberfläche stellt verschiedene Felder zum Konfigurieren des Knoten bereit (Name, Kontakt, Geo-Koordinaten, Bandbreitenlimitierung, …) und ist weitgehend selbsterklärend. Nach abschließen der Konfiguration muss der Router nochmals neu gestartet werden. Auch kann er nun wieder mit dem lokalen Heim-Netzwerk verbunden werden, so dass er ggf. übers Internet eine Verbindung zum Freifunk-VPN-Gateway herstellen kann. Der Router startet nun in den Normal-Mode: Die grüne LED leuchtet dauerhaft.

Für erfahrene Benutzer gibt es zusätzlich zum Normal-Mode und Config-Mode auch noch den Failsafe-Mode. Dieser kann erreicht werden wenn im Bootvorgang des Routers mehrfach die Reset-Taste gedrückt wird. Im Failsafe-Mode blinkt die grüne LED sehr schnell (schneller als 1x pro Sekunde). In diesem Modus sind alle Services deaktiviert und der Router ist nur per Telnet/SSH auf 192.168.1.1 zu erreichen.
(Quelle 1, Quelle 2, Quelle 3)

Viel Spaß mit eurem eigenen Freifunk-Knoten!