mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-03-24 02:20:09 +08:00
Merge remote-tracking branch 'LCTT/master'
This commit is contained in:
Xingyu Wang
commit
a154196838
@ -1,5 +1,5 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: translator: ( chenmu-kk )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
|
||||
@ -0,0 +1,130 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (Is open source a development model, business model, or something else?)
|
||||
[#]: via: (https://opensource.com/article/20/10/open-source-supply-chain)
|
||||
[#]: author: (Scott McCarty https://opensource.com/users/fatherlinux)
|
||||
|
||||
Is open source a development model, business model, or something else?
|
||||
======
|
||||
Instead of asking whether open source is a development model or a
|
||||
business model, start thinking about it as a supply chain for your
|
||||
products.
|
||||
![Net catching 1s and 0s or data in the clouds][1]
|
||||
|
||||
The term "open source" was coined in 1998 at a strategy session held by [Open Source Initiative][2] (OSI). The OSI maintains the [Open Source Definition][3] (OSD), which places mandates on the distribution terms of any software that claims to be open source. The OSI also maintains a curated list of official [open source licenses][4] that meet these guidelines.
|
||||
|
||||
The OSD gives a clear definition of what open source software _is_, but doesn't provide much insight into how the adoption of open source affects a company's ability to build and deliver products or services that people want and need. Stated another way, there's still tremendous debate about the best ways to build a business based on open source.
|
||||
|
||||
In this first of a multi-part series, I will lay the groundwork for understanding what products are, what product managers do, and how open source can be considered a supply chain. In future articles, I will go deeper into each of these topics, but I'll start by dissecting some common, but fundamentally confusing vocabulary.
|
||||
|
||||
### Development model or business model?
|
||||
|
||||
Open source adoption is common in products and solutions, but the verdict is out on what this truly means for product teams. Is open source a software development model or a business model? Even today, there are huge debates in open source circles.
|
||||
|
||||
People who think of open source [as a development model][5] emphasize collaboration, the decentralized nature in which code is written, and the licenses under which that code is released. Those who think of open source [as a business model][6] discuss monetization through support, services, software-as-a-service, paid features, and even in the context of inexpensive marketing or advertising. While there are surely valid arguments on both sides, neither of these models has ever satisfied everyone. Perhaps it's because we've never fully considered open source in the historical context of software products and their practical construction.
|
||||
|
||||
> Instead of thinking about open source as a development model or a business model, perhaps companies should think in terms of a supply chain from which they can purchase technology.
|
||||
|
||||
A [supply chain][7] includes the organizations, people, activities, information, and resources needed to create any product or service. This includes products as simple as a wool coat or as complex as an open source software project with thousands of dependencies. In [_The Wealth of Nations_][8], the father of economics, [Adam Smith][9], describes the supply chain for a wool coat:
|
||||
|
||||
> "The shepherd, the sorter of the wool, the wool-comber or carder, the dyer, the scribbler, the spinner, the weaver, the fuller, the dresser, with many others, must all join their different arts in order to complete even this homely production."
|
||||
|
||||
![Wool coat supply chain][10]
|
||||
|
||||
(Scott McCarty, [CC BY-SA 4.0][11])
|
||||
|
||||
Most of us probably haven't heard of the roles involved in the supply chain for a wool coat, but one thing is obvious: divisions of labor and collaboration are keys to a healthy supply chain, especially with open source.
|
||||
|
||||
### Product or project?
|
||||
|
||||
If you accept that open source is a supply chain for building solutions, this leads to another misunderstanding around projects and products. Paul Cormier, Red Hat's CEO, makes a pragmatic distinction between [open source _projects_ and open source _products_][12]. While I agree with Paul, I am obliged to confess that most of the world doesn't recognize this crisp distinction. In 20 years of conversations with customers, partners, users, contributors, analysts, journalists, and even my own family, most people use the words _project_ and _product_ interchangeably.
|
||||
|
||||
I'll attempt to bring clarity by proposing a simple definition: Products are things that people buy with currency, while projects are things people participate in, contribute to, or use. That gets part of the way to a better definition, but to truly understand, you need to define what a product _is_ in order to clearly see what a project _isn't_.
|
||||
|
||||
Software products, like any other products or services, have a whole host of activities required to bring them to market. They have business plans, pricing and packaging, positioning and messaging, distribution strategies, sales enablement, portfolio alignment, build/buy/partner decisions, and roadmaps. The teams managing these products conduct focus groups, analyze addressable markets, brief journalists and analysts about how their products fit into the marketplace, walk customers through roadmaps, and, most importantly, define those roadmaps based on the needs of paying customers. Product teams spend a lot of time and money understanding their customers' problems, but this is rarely the work output of community members.
|
||||
|
||||
Product teams have a fundamental choice about which suppliers they use in their products. This could mean using two, three, four, or even 10 different upstream projects in a product. It could also mean switching upstream projects when they no longer meet the needs of the customers buying the product. Finally, it could also mean positioning a partner's solution or different parts of the product portfolio to fill in gaps (i.e., address customer needs with solutions). The product team can also decide to use open source as one part of the supply chain and proprietary software as another part, thereby differentiating the product from the project. They can even make their product available only as a service; this is the power of pricing and packaging.
|
||||
|
||||
Nearly all products are built by adding a layer of differentiated value to a set of commodity components that are provided by suppliers. This is true, whether they're built on open source or proprietary components. Stated another way, upstream suppliers cannot provide the same solution as downstream products. When upstream projects and downstream products tackle the exact same business problem, there is low differentiation, which creates challenges. This is akin to upstream suppliers and the downstream product company both selling tires—the upstream supplier needs to sell tires, and the downstream product company needs to sell vehicles.
|
||||
|
||||
> A lack of differentiation between the supply-chain components and the downstream product is where open source companies run into problems.
|
||||
|
||||
Everyday, product teams have to make pricing, packaging, build, buy, partner, and roadmap decisions driven by paying customers. This is what provides differentiation to a product and makes it fundamentally different from a community-driven, open source project.
|
||||
|
||||
### Buying from the open source supply chain
|
||||
|
||||
Open source technology is free as in speech, not "free as in beer." Anyone can download and use open source software pretty much however they want, but as soon as you sell a product that uses open source, you have a responsibility to the customer. That responsibility includes things like verifying the software is always patched, secure, and runs well. A product team has a commitment to the customers and is responsible for every component chosen in the supply chain.
|
||||
|
||||
![Stephen Walli tweet about open source business models][13]
|
||||
|
||||
(Scott McCarty, [CC BY-SA 4.0][11])
|
||||
|
||||
Stated another way, building a product on open source software is not free. It costs [either time or money][14], and everyone knows time is money, so these are essentially the same thing. Therefore, it's genuinely correct to use the word "buy" to describe the relationship between product teams and the upstream open source projects that supply technology for those products.
|
||||
|
||||
From the perspective of the product team, each upstream project can be thought of as a supplier. The product team can "buy" from the open source suppliers by contributing the time and energy of engineers, documentation writers, testers, etc. Since time is money, every hour spent on upstream work can be measured in dollars.
|
||||
|
||||
This cost of consuming from the open source supply chain exists whether your organization is selling a _product_ based on open source or building a _solution_ for internal consumption. Building anything on open source comes with an implicit responsibility for the components selected and used. But, unlike a traditional supply chain, a dollar may not be a dollar (fill in your currency of choice).
|
||||
|
||||
Every dollar invested in an open source supply chain purchase might return $2, $3, or even $10 of value in return. The return on investment can be higher because other people and companies are also contributing value, as well as a diversity of ideas. Everyone who consumes from an open source supply chain inherits the total value. If the community is healthy, the value received is far above and beyond the contributions made.
|
||||
|
||||
There's another hidden benefit to purchasing from open source suppliers. Unlike traditional suppliers, community-driven, open source projects are not profit-driven entities with sales, marketing, and go-to-market costs. This is akin to buying from non-profit entities, but, once again, it's not "free as in beer." There's definitely a cost associated with purchasing from an open source supply chain and, in turn, providing a product to your customers.
|
||||
|
||||
### A better metaphor for products
|
||||
|
||||
Perhaps no one has ever taken a product-centric view of open source because it grew up alongside the internet and the dot-com boom. This was a time of throwing money at ideas without having much of a business plan. Attempts to apply traditional business understanding _post facto_ have led to debate over the definition of open source versus [open core][15], as well as the roles and responsibilities of product teams. The software industry, and open source, in particular, has been notoriously confused about aligning product management and upstream engineering. The blurry line between project and product has even led to misunderstandings about what features upstream projects should focus on versus the downstream products.
|
||||
|
||||
Working as a member of the product team driving the roadmap for arguably the largest open source product in the world, Red Hat Enterprise Linux, I'd like to humbly propose a new paradigm within which to think about open source software:
|
||||
|
||||
> **Open source is a supply chain model.**
|
||||
|
||||
It's not a huge intellectual leap, but this has profound implications on discussions, debates, and cognitive load when thinking about products that leverage open source.
|
||||
|
||||
### Capturing value with open source
|
||||
|
||||
In recent years, arguments have been put forth asserting that there [can only ever be one Red Hat][16]; the narrative implies that only one company can grow into a multi-billion dollar business by selling support. This narrative is problematic because Red Hat doesn't make money from support, and it might even be argued that [Red Hat Network][17] was the first SaaS of open source. Second, other companies like SUSE, Cloudera, and Chef have captured quite a bit of value. Finally, many businesses start with a SaaS model and extend into adjacent on-premises businesses, like [CloudBees][18].
|
||||
|
||||
All of these companies have been able to successfully use open source as a supply chain to create value while simultaneously capturing value by satisfying complex business problems that are not solved by the upstream project alone. Fundamentally, SaaS and hardware/software combinations are no different, although it might be argued that they are easier to monetize.
|
||||
|
||||
Fellow product managers, I urge you to start thinking about open source projects as a supply chain for your products. It will give you new clarity in making product-driven decisions and focusing on business needs instead of technology. With all supply chains, product managers have to treat their suppliers fairly. For example, downstream product teams can't tell upstream suppliers what to do. Downstream product teams also have to pay suppliers enough to keep them in business and continue to supply technology. These are just two examples of the clarity that comes from treating upstream, open source projects as suppliers, and it keeps the relationship much healthier.
|
||||
|
||||
![Linux supply chain][19]
|
||||
|
||||
(Scott McCarty, [CC BY-SA 4.0][11])
|
||||
|
||||
There's a saying in music: _It's not the notes you play, but the notes you don't play._ Constraints breed creativity. If you know you can't differentiate your product based on the code from your upstream suppliers, your product team has to get creative. You have to identify other value worth purchasing. I'll dig into this later in the series; in the next article, I'll add clarity to the scope of what an open source product is and how to create value with it.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/10/open-source-supply-chain
|
||||
|
||||
作者：[Scott McCarty][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/fatherlinux
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/data_analytics_cloud.png?itok=eE4uIoaB (Net catching 1s and 0s or data in the clouds)
|
||||
[2]: https://opensource.org/
|
||||
[3]: https://opensource.org/osd
|
||||
[4]: https://opensource.org/licenses/alphabetical
|
||||
[5]: https://en.wikipedia.org/wiki/Open-source_model
|
||||
[6]: https://opensource.com/article/17/12/open-source-business-models
|
||||
[7]: https://en.wikipedia.org/wiki/Supply_chain
|
||||
[8]: https://en.wikipedia.org/wiki/The_Wealth_of_Nations
|
||||
[9]: https://en.wikipedia.org/wiki/Adam_Smith
|
||||
[10]: https://opensource.com/sites/default/files/uploads/wool_coat_supply_chain.png (Wool coat supply chain)
|
||||
[11]: https://creativecommons.org/licenses/by-sa/4.0/
|
||||
[12]: https://siliconangle.com/2019/05/10/red-hat-talks-project-vs-product-in-enterprise-open-source-rhsummit/
|
||||
[13]: https://opensource.com/sites/default/files/uploads/tweet.png (Stephen Walli tweet about open source business models)
|
||||
[14]: https://twitter.com/stephenrwalli/status/1147205594966663168
|
||||
[15]: https://medium.com/open-consensus/2-open-core-definition-examples-tradeoffs-e4d0c044da7c
|
||||
[16]: https://techcrunch.com/2014/02/13/please-dont-tell-me-you-want-to-be-the-next-red-hat/
|
||||
[17]: https://en.wikipedia.org/wiki/Red_Hat_Network
|
||||
[18]: https://www.cloudbees.com/blog/enhanced-pricing-and-packaging-cloudbees-platform
|
||||
[19]: https://opensource.com/sites/default/files/uploads/linux_supply_chain.png (Linux supply chain)
|
||||
@ -1,5 +1,5 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: translator: (MjSeven)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
|
||||
132
sources/tech/20201016 Set up ZFS on Linux with yum.md
Normal file
132
sources/tech/20201016 Set up ZFS on Linux with yum.md
Normal file
@ -0,0 +1,132 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (Set up ZFS on Linux with yum)
|
||||
[#]: via: (https://opensource.com/article/20/10/zfs-dnf)
|
||||
[#]: author: (Sheng Mao https://opensource.com/users/ivzhh)
|
||||
|
||||
Set up ZFS on Linux with yum
|
||||
======
|
||||
Use a yum repo to take advantage of the latest ZFS features on Fedora.
|
||||
![Puzzle pieces coming together to form a computer screen][1]
|
||||
|
||||
I am a Fedora Linux user who runs `yum upgrade` daily. While this habit enables me to run all the latest software (one of [Fedora's four foundations][2] is "first," and it lives up to that), it also highlights any incompatibilities between the [ZFS][3] storage platform and a new kernel.
|
||||
|
||||
As a developer, sometimes I need new features from the latest ZFS branch. For example, ZFS 2.0.0 contains an exciting new feature greatly [improving ZVOL sync performance][4], which is critical to me as a KVM user. But this means that if I want to use the 2.0.0 branch, I have to build ZFS myself.
|
||||
|
||||
At first, I just compiled ZFS manually from its Git repo after every kernel update. If I forgot, ZFS would fail to be recognized on the next boot. Luckily, I quickly learned how to set up dynamic kernel module support ([DKMS][5]) for ZFS. However, this solution isn't perfect. For one thing, it doesn't utilize the powerful [yum][6] system, which can help with resolving dependencies and upgrading. In addition, switching between your own package and an upstream package is pretty easy with yum.
|
||||
|
||||
In this article, I will demonstrate how to set up a yum repo for packaging ZFS. The solution has two steps:
|
||||
|
||||
1. Create RPM packages from the ZFS Git repository
|
||||
2. Set up a yum repo to host the packages
|
||||
|
||||
|
||||
|
||||
### Create RPM packages
|
||||
|
||||
To create RPM packages, you need to install the RPM toolchain. Yum provides groups to bundle installing the tools:
|
||||
|
||||
|
||||
```
|
||||
`sudo dnf group install 'C Development Tools and Libraries' 'RPM Development Tools'`
|
||||
```
|
||||
|
||||
After these have been installed, you must install all the packages necessary to build ZFS from the ZFS Git repo. The packages belong to three groups:
|
||||
|
||||
1. [Autotools][7] to generate build files from platform configurations
|
||||
2. Libraries for building ZFS kernel and userland tools
|
||||
3. Libraries for building RPM packages
|
||||
|
||||
|
||||
|
||||
|
||||
```
|
||||
sudo dnf install libtool autoconf automake gettext createrepo \
|
||||
libuuid-devel libblkid-devel openssl-devel libtirpc-devel \
|
||||
lz4-devel libzstd-devel zlib-devel \
|
||||
kernel-devel elfutils-libelf-devel \
|
||||
libaio-devel libattr-devel libudev-devel \
|
||||
python3-devel libffi-devel
|
||||
```
|
||||
|
||||
Now you are ready to create your own packages.
|
||||
|
||||
### Build OpenZFS
|
||||
|
||||
[OpenZFS][8] provides excellent infrastructure. To build it:
|
||||
|
||||
1. Clone the repository with `git` and switch to the branch/tag that you hope to use.
|
||||
2. Run Autotools to generate a makefile.
|
||||
3. Run `make rpm` and, if everything works, RPM files will be placed in the build folder.
|
||||
|
||||
|
||||
|
||||
|
||||
```
|
||||
$ git clone --branch=zfs-2.0.0-rc3 <https://github.com/openzfs/zfs.git> zfs
|
||||
$ cd zfs
|
||||
$ ./autogen.sh
|
||||
$ ./configure
|
||||
$ make rpm
|
||||
```
|
||||
|
||||
### Set up a yum repo
|
||||
|
||||
In yum, a repo is a server or local path that includes metadata and RPM files. A consumer sets up an INI configuration file, and the `yum` command automatically resolves the metadata and downloads the corresponding packages.
|
||||
|
||||
Fedora provides the `createrepo` tool to set up a yum repo. First, create the repo and copy all RPM files from the ZFS folder to the repo. Then run `createrepo --update` to include all packages in the metadata:
|
||||
|
||||
|
||||
```
|
||||
$ sudo mkdir -p /var/lib/zfs.repo
|
||||
$ sudo createrepo /var/lib/zfs.repo
|
||||
$ sudo cp *.rpm /var/lib/zfs.repo/
|
||||
$ sudo createrepo --update /var/lib/zfs.repo
|
||||
```
|
||||
|
||||
Create a new configuration file in `/etc/yum.repos.d` to include the repo path:
|
||||
|
||||
|
||||
```
|
||||
$ echo \
|
||||
"[zfs-local]\\\nname=ZFS Local\\\nbaseurl=file:///var/lib/zfs.repo\\\nenabled=1\\\ngpgcheck=0" |\
|
||||
sudo tee /etc/yum.repos.d/zfs-local.repo
|
||||
|
||||
$ sudo dnf --repo=zfs-local list available --refresh
|
||||
```
|
||||
|
||||
Finally, you have reached the end of the journey! You have a working yum repo and ZFS packages. Now you just need to install them:
|
||||
|
||||
|
||||
```
|
||||
$ sudo dnf install zfs
|
||||
$ sudo /sbin/modprobe zfs
|
||||
```
|
||||
|
||||
Run `sudo zfs version` to see the version of your userland and kernel tools. Congratulations! You have [ZFS for Fedora][9].
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/10/zfs-dnf
|
||||
|
||||
作者：[Sheng Mao][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/ivzhh
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/puzzle_computer_solve_fix_tool.png?itok=U0pH1uwj (Puzzle pieces coming together to form a computer screen)
|
||||
[2]: https://docs.fedoraproject.org/en-US/project/#_what_is_fedora_all_about
|
||||
[3]: https://zfsonlinux.org/
|
||||
[4]: https://www.phoronix.com/scan.php?page=news_item&px=OpenZFS-3x-Boost-Sync-ZVOL
|
||||
[5]: https://www.linuxjournal.com/article/6896
|
||||
[6]: https://en.wikipedia.org/wiki/Yum_%28software%29
|
||||
[7]: https://opensource.com/article/19/7/introduction-gnu-autotools
|
||||
[8]: https://openzfs.org/wiki/Main_Page
|
||||
[9]: https://openzfs.github.io/openzfs-docs/Getting%20Started/Fedora.html
|
||||
@ -0,0 +1,162 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (systemd-resolved: introduction to split DNS)
|
||||
[#]: via: (https://fedoramagazine.org/systemd-resolved-introduction-to-split-dns/)
|
||||
[#]: author: (zbyszek https://fedoramagazine.org/author/zbyszek/)
|
||||
|
||||
systemd-resolved: introduction to split DNS
|
||||
======
|
||||
|
||||
![][1]
|
||||
|
||||
Photo by [Ruvim Noga][2] on [Unsplash][3]
|
||||
|
||||
Fedora 33 switches the default DNS resolver to [systemd-resolved][4]. In simple terms, this means that systemd-resolved will run as a daemon. All programs wanting to translate domain names to network addresses will talk to it. This replaces the current default lookup mechanism where each program individually talks to remote servers and there is no shared cache.
|
||||
|
||||
If necessary, systemd-resolved will contact remote DNS servers. systemd-resolved is a “stub resolver”—it doesn’t resolve all names itself (by starting at the root of the DNS hierarchy and going down label by label), but forwards the queries to a remote server.
|
||||
|
||||
A single daemon handling name lookups provides significant benefits. The daemon caches answers, which speeds answers for frequently used names. The daemon remembers which servers are non-responsive, while previously each program would have to figure this out on its own after a timeout. Individual programs only talk to the daemon over a local transport and are more isolated from the network. The daemon supports fancy rules which specify which name servers should be used for which domain names—in fact, the rest of this article is about those rules.
|
||||
|
||||
### Split DNS
|
||||
|
||||
Consider the scenario of a machine that is connected to two semi-trusted networks (wifi and ethernet), and also has a VPN connection to your employer. Each of those three connections has its own network interface in the kernel. And there are multiple name servers: one from a DHCP lease from the wifi hotspot, two specified by the VPN and controlled by your employer, plus some additional manually-configured name servers. _Routing_ is the process of deciding which servers to ask for a given domain name. Do not mistake this with the process of deciding where to send network packets, which is called routing too.
|
||||
|
||||
The network interface is king in systemd-resolved. systemd-resolved first picks one or more interfaces which are appropriate for a given name, and then queries one of the name servers attached to that interface. This is known as “split DNS”.
|
||||
|
||||
There are two flavors of domains attached to a network interface: _routing domains_ and _search domains_. They both specify that the given domain and any subdomains are appropriate for that interface. Search domains have the additional function that single-label names are suffixed with that search domain before being resolved. For example, a lookup for “server” is treated as a lookup for “server.example.com” if the search domain is “example.com.” In systemd-resolved config files, routing domains are prefixed with the tilde (~) character.
|
||||
|
||||
#### Specific example
|
||||
|
||||
Now consider a specific example: your VPN interface _tun0_ has a search domain _private.company.com_ and a routing domain _~company.com_. If you ask for _mail.private.company.com_, it is matched by both domains, so this name would be routed to _tun0_.
|
||||
|
||||
A request for _[www.company.com][5]_ is matched by the second domain and would also go to _tun0_. If you ask for _www_, (in other words, if you specify a single-label name without any dots), the difference between routing and search domains comes into play. systemd-resolved attempts to combine the single-label name with the search domain and tries to resolve _[www.private.company.com][6]_ on _tun0_.
|
||||
|
||||
If you have multiple interfaces with search domains, single-label names are suffixed with all search domains and resolved in parallel. For multi-label names, no suffixing is done; search and routing domains are are used to route the name to the appropriate interface. The longest match wins. When there are multiple matches of the same length on different interfaces, they are resolved in parallel.
|
||||
|
||||
A special case is when an interface has a routing domain _~._ (a tilde for a routing domain and a dot for the root DNS label). Such an interface always matches any names, but with the shortest possible length. Any interface with a matching search or routing domain has higher priority, but the interface with _~._ is used for all other names. Finally, if no routing or search domains matched, the name is routed to all interfaces that have at least one name server attached.
|
||||
|
||||
### Lookup routing in systemd-resolved
|
||||
|
||||
#### Domain routing
|
||||
|
||||
This seems fairly complex, partially because of the historic names which are confusing. In actual practice it’s not as complicated as it seems.
|
||||
|
||||
To introspect a running system, use the _resolvectl domain_ command. For example:
|
||||
|
||||
```
|
||||
$ resolvectl domain
|
||||
Global:
|
||||
Link 4 (wlp4s0): ~.
|
||||
Link 18 (hub0):
|
||||
Link 26 (tun0): redhat.com
|
||||
```
|
||||
|
||||
You can see that _www_ would resolve as _[www.redhat.com][7]_. over _tun0_. Anything ending with _redhat.com_ resolves over _tun0_. Everything else would resolve over _wlp4s0_ (the wireless interface). In particular, a multi-label name like _[www.foobar][8]_ would resolve over _wlp4s0_, and most likely fail because there is no _foobar_ top-level domain (yet).
|
||||
|
||||
#### Server routing
|
||||
|
||||
Now that you know which _interface_ or interfaces should be queried, the _server_ or servers to query are easy to determine. Each interface has one or more name servers configured. systemd-resolved will send queries to the first of those. If the server is offline and the request times out or if the server sends a syntactically-invalid answer (which shouldn’t happen with “normal” queries, but often becomes an issue when DNSSEC is enabled), systemd-resolved switches to the next server on the list. It will use that second server as long as it keeps responding. All servers are used in a round-robin rotation.
|
||||
|
||||
To introspect a running system, use the _resolvectl dns_ command:
|
||||
|
||||
```
|
||||
$ resolvectl dns
|
||||
Global:
|
||||
Link 4 (wlp4s0): 192.168.1.1 8.8.4.4 8.8.8.8
|
||||
Link 18 (hub0):
|
||||
Link 26 (tun0): 10.45.248.15 10.38.5.26
|
||||
```
|
||||
|
||||
When combined with the previous listing, you know that for _[www.redhat.com][7]_, systemd-resolved will query 10.45.248.15, and—if it doesn’t respond—10.38.5.26. For _[www.google.com][9]_, systemd-resolved will query 192.168.1.1 or the two Google servers 8.8.4.4 and 8.8.8.8.
|
||||
|
||||
### Differences from nss-dns
|
||||
|
||||
Before going further detail, you may ask how this differs from the previous default implementation (nss-dns). With nss-dns there is just one global list of up to three name servers and a global list of search domains (specified as _nameserver_ and _search_ in _/etc/resolv.conf_).
|
||||
|
||||
Each name to query is sent to the first name server. If it doesn’t respond, the same query is sent to the second name server, and so on. systemd-resolved implements split-DNS and remembers which servers are currently considered active.
|
||||
|
||||
For single-label names, the query is performed with each of the the search domains suffixed. This is the same with systemd-resolved. For multi-label names, a query for the unsuffixed name is performed first, and if that fails, a query for the name suffixed by each of the search domains in turn is performed. systemd-resolved doesn’t do that last step; it only suffixes single-label names.
|
||||
|
||||
A second difference is that with _nss-dns_, this module is loaded into each process. The process itself communicates with remote servers and implements the full DNS stack internally. With systemd-resolved, the _nss-resolve_ module is loaded into the process, but it only forwards the query to systemd-resolved over a local transport (D-Bus) and doesn’t do any work itself. The systemd-resolved process is heavily sandboxed using systemd service features.
|
||||
|
||||
The third difference is that with systemd-resolved all state is dynamic and can be queried and updated using D-Bus calls. This allows very strong integration with other daemons or graphical interfaces.
|
||||
|
||||
### Configuring systemd-resolved
|
||||
|
||||
So far, this article talked about servers and the routing of domains without explaining how to configure them. systemd-resolved has a configuration file (_/etc/systemd/resolv.conf_) where you specify name servers with _DNS=_ and routing or search domains with _Domains=_ (routing domains with _~_, search domains without). This corresponds to the _Global:_ lists in the two listings above.
|
||||
|
||||
In this article’s examples, both lists are empty. Most of the time configuration is attached to specific interfaces, and “global” configuration is not very useful. Interfaces come and go and it isn’t terribly smart to contact servers on an interface which is down. As soon as you create a VPN connection, you want to use the servers configured for that connection to resolve names, and as soon as the connection goes down, you want to stop.
|
||||
|
||||
How does then systemd-resolved acquire the configuration for each interface? This happens dynamically, with the network management service pushing this configuration over D-Bus into systemd-resolved. The default in Fedora is NetworkManager and it has very good integration with systemd-resolved. Alternatives like systemd’s own systemd-networkd implement similar functionality. But the [interface is open][10] and other programs can do the appropriate D-Bus calls.
|
||||
|
||||
Alternatively, _resolvectl_ can be used for this (it is just a wrapper around the D-Bus API). Finally, _resolvconf_ provides similar functionality in a form compatible with a tool in Debian with the same name.
|
||||
|
||||
#### Scenario: Local connection more trusted than VPN
|
||||
|
||||
The important thing is that in the common scenario, systemd-resolved follows the configuration specified by other tools, in particular NetworkManager. So to understand how systemd-resolved names, you need to see what NetworkManager tells it to do. Normally NM will tell systemd-resolved to use the name servers and search domains received in a DHCP lease on some interface. For example, look at the source of configuration for the two listings shown above:
|
||||
|
||||
![][11]![][12]
|
||||
|
||||
There are two connections: “Parkinson” wifi and “Brno (BRQ)” VPN. In the first panel _DNS:Automatic_ is enabled, which means that the DNS server received as part of the DHCP lease (192.168.1.1) is passed to systemd-resolved. Additionally. 8.8.4.4 and 8.8.8.8 are listed as alternative name servers. This configuration is useful if you want to resolve the names of other machines in the local network, which 192.168.1.1 provides. Unfortunately the hotspot DNS server occasionally gets stuck, and the other two servers provide backup when that happens.
|
||||
|
||||
The second panel is similar, but doesn’t provide any special configuration. NetworkManager combines routing domains for a given connection from DHCP, SLAAC RDNSS, and VPN, and finally manual configuration and forward this to systemd-resolved. This is the source of the search domain _redhat.com_ in the listing above.
|
||||
|
||||
There is an important difference between the two interfaces though: in the second panel, “Use this connection only for resources on its network” is **checked**. This tells NetworkManager to tell systemd-resolved to only use this interface for names under the search domain received as part of the lease (_Link 26 (tun0): redhat.com_ in the first listing above). In the first panel, this checkbox is **unchecked**, and NetworkManager tells systemd-resolved to use this interface for all other names (_Link 4 (wlp4s0): ~._). This effectively means that the wireless connection is more trusted.
|
||||
|
||||
#### Scenario: VPN more trusted than local network
|
||||
|
||||
In a different scenario, a VPN would be more trusted than the local network and the domain routing configuration reversed. If a VPN without “Use this connection only for resources on its network” is active, NetworkManager tells systemd-resolved to attach the default routing domain to this interface. After unchecking the checkbox and restarting the VPN connection:
|
||||
|
||||
```
|
||||
$ resolvectl domain
|
||||
Global:
|
||||
Link 4 (wlp4s0):
|
||||
Link 18 (hub0):
|
||||
Link 28 (tun0): ~. redhat.com
|
||||
$ resolvectl dns
|
||||
Global:
|
||||
Link 4 (wlp4s0):
|
||||
Link 18 (hub0):
|
||||
Link 28 (tun0): 10.45.248.15 10.38.5.26
|
||||
```
|
||||
|
||||
Now all domain names are routed to the VPN. The network management daemon controls systemd-resolved and the user controls the network management daemon.
|
||||
|
||||
### Additional systemd-resolved functionality
|
||||
|
||||
As mentioned before, systemd-resolved provides a common name lookup mechanism for all programs running on the machine. Right now the effect is limited: shared resolver and cache and split DNS (the lookup routing logic described above). systemd-resolved provides additional resolution mechanisms beyond the traditional unicast DNS. These are the local resolution protocols MulticastDNS and LLMNR, and an additional remote transport DNS-over-TLS.
|
||||
|
||||
Fedora 33 does not enable MulticastDNS and DNS-over-TLS in systemd-resolved. MulticastDNS is implemented by _nss-mdns4_minimal_ and Avahi. Future Fedora releases may enable these as the upstream project improves support.
|
||||
|
||||
Implementing this all in a single daemon which has runtime state allows smart behaviour: DNS-over-TLS may be enabled in opportunistic mode, with automatic fallback to classic DNS if the remote server does not support it. Without the daemon which can contain complex logic and runtime state this would be much harder. When enabled, those additional features will apply to all programs on the system.
|
||||
|
||||
There is more to systemd-resolved: in particular LLMNR and DNSSEC, which only received brief mention here. A future article will explore those subjects.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://fedoramagazine.org/systemd-resolved-introduction-to-split-dns/
|
||||
|
||||
作者：[zbyszek][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://fedoramagazine.org/author/zbyszek/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://fedoramagazine.org/wp-content/uploads/2020/10/systemd-resolved2-816x345.jpg
|
||||
[2]: https://unsplash.com/@ruvimnogaphoto?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText
|
||||
[3]: https://unsplash.com/s/photos/colors?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText
|
||||
[4]: https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html
|
||||
[5]: http://www.company.com
|
||||
[6]: http://www.private.company.com
|
||||
[7]: http://www.redhat.com
|
||||
[8]: http://www.foobar
|
||||
[9]: http://www.google.com
|
||||
[10]: https://www.freedesktop.org/software/systemd/man/org.freedesktop.resolve1.html
|
||||
[11]: https://fedoramagazine.org/wp-content/uploads/2020/10/nm-default-network-with-additional-servers.png
|
||||
[12]: https://fedoramagazine.org/wp-content/uploads/2020/10/nm-vpn-brno.png
|
||||
Loading…
Reference in New Issue
Block a user