mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-03-21 02:10:11 +08:00
Merge remote-tracking branch 'LCTT/master'
This commit is contained in:
Xingyu Wang
commit
1ac298fb0a
@ -0,0 +1,57 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: (wxy)
|
||||
[#]: publisher: (wxy)
|
||||
[#]: url: (https://linux.cn/article-11564-1.html)
|
||||
[#]: subject: (Cloning a MAC address to bypass a captive portal)
|
||||
[#]: via: (https://fedoramagazine.org/cloning-a-mac-address-to-bypass-a-captive-portal/)
|
||||
[#]: author: (Esteban Wilson https://fedoramagazine.org/author/swilson/)
|
||||
|
||||
克隆 MAC 地址来绕过强制门户
|
||||
======
|
||||
|
||||
![][1]
|
||||
|
||||
如果你曾经在家和办公室之外连接到 WiFi，那么通常会看到一个门户页面。它可能会要求你接受服务条款或其他协议才能访问。但是，当你无法通过这类门户进行连接时会发生什么？本文向你展示了如何在 Fedora 上使用 NetworkManager 在某些故障情况下让你仍然可以访问互联网。
|
||||
|
||||
### 强制门户如何工作
|
||||
|
||||
强制门户是新设备连接到网络时显示的网页。当用户首次访问互联网时，门户网站会捕获所有网页请求并将其重定向到单个门户页面。
|
||||
|
||||
然后，页面要求用户采取一些措施，通常是同意使用政策。用户同意后，他们可以向 RADIUS 或其他类型的身份验证系统进行身份验证。简而言之，强制门户根据设备的 MAC 地址和终端用户接受条款来注册和授权设备。（MAC 地址是附加到任何网络接口的[基于硬件的值][2]，例如 WiFi 芯片或卡。）
|
||||
|
||||
有时设备无法加载强制门户来进行身份验证和授权以使用 WiFI 接入。这种情况的例子包括移动设备和游戏机（Switch、Playstation 等）。当连接到互联网时，它们通常不会打开强制门户页面。连接到酒店或公共 WiFi 接入点时，你可能会看到这种情况。
|
||||
|
||||
不过，你可以在 Fedora 上使用 NetworkManager 来解决这些问题。Fedora 可以使你临时克隆要连接的设备的 MAC 地址，并代表该设备通过强制门户进行身份验证。你需要得到连接设备的 MAC 地址。通常，它被打印在设备上的某个地方并贴上标签。它是一个六字节的十六进制值，因此看起来类似 `4A:1A:4C:B0:38:1F`。通常，你也可以通过设备的内置菜单找到它。
|
||||
|
||||
### 使用 NetworkManager 克隆
|
||||
|
||||
首先，打开 `nm-connection-editor`，或通过“设置”打开 WiFi 设置。然后，你可以使用 NetworkManager 进行克隆：
|
||||
|
||||
* 对于以太网：选择已连接的以太网连接。然后选择 “Ethernet” 选项卡。记录或复制当前的 MAC 地址。在 “<ruby>克隆 MAC 地址<rt>Cloned MAC address</rt></ruby>” 字段中输入游戏机或其他设备的 MAC 地址。
|
||||
* 对于 WiFi：选择 WiFi 配置名。然后选择 “WiFi” 选项卡。记录或复制当前的 MAC 地址。在 “<ruby>克隆 MAC 地址<rt>Cloned MAC address</rt></ruby>” 字段中输入游戏机或其他设备的 MAC 地址。
|
||||
|
||||
### 启动所需的设备
|
||||
|
||||
当 Fedora 系统与以太网或 WiFi 配置连接，克隆的 MAC 地址将用于请求 IP 地址，并加载强制门户。输入所需的凭据和/或选择用户协议。该 MAC 地址将获得授权。
|
||||
|
||||
现在，断开 WiF i或以太网配置连接，然后将 Fedora 系统的 MAC 地址更改回其原始值。然后启动游戏机或其他设备。该设备现在应该可以访问互联网了，因为它的网络接口已通过你的 Fedora 系统进行了授权。
|
||||
|
||||
不过，这不是 NetworkManager 全部能做的。例如，请参阅[随机化系统硬件地址][3]，来获得更好的隐私保护。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://fedoramagazine.org/cloning-a-mac-address-to-bypass-a-captive-portal/
|
||||
|
||||
作者：[Esteban Wilson][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://fedoramagazine.org/author/swilson/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://fedoramagazine.org/wp-content/uploads/2019/10/clone-mac-nm-816x345.jpg
|
||||
[2]: https://en.wikipedia.org/wiki/MAC_address
|
||||
[3]: https://linux.cn/article-10028-1.html
|
||||
@ -0,0 +1,62 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (Why containers and Kubernetes have the potential to run almost anything)
|
||||
[#]: via: (https://opensource.com/article/19/6/kubernetes-potential-run-anything)
|
||||
[#]: author: (Scott McCarty https://opensource.com/users/fatherlinux)
|
||||
|
||||
Why containers and Kubernetes have the potential to run almost anything
|
||||
======
|
||||
Go beyond deployment of simple applications and tackle day two
|
||||
operations with Kubernetes Operators.
|
||||
![arrows cycle symbol for failing faster][1]
|
||||
|
||||
In my first article, _[Kubernetes is a dump truck: Here's why][2]_, I talked about about how Kubernetes is elegant at defining, sharing, and running applications, similar to how dump trucks are elegant at moving dirt. In the second, _[How to navigate the Kubernetes learning curve][3]_, I explain that the learning curve for Kubernetes is really the same learning curve for running any applications in production, which is actually easier than learning all of the traditional pieces (load balancers, routers, firewalls, switches, clustering software, clustered files systems, etc). This is DevOps, a collaboration between Developers and Operations to specify the way things should run in production, which means there's a learning curve for both sides. In article four, _[Kubernetes basics: Learn how to drive first][4]_, I reframe learning Kubernetes with a focus on driving the dump truck instead of building or equipping it. In the fourth article, _[4 tools to help you drive Kubernetes][5]_, I share tools that I have fallen in love with to help build applications (drive the dump truck) in Kubernetes.
|
||||
|
||||
In this final article, I share the reasons why I am so excited about the future of running applications on Kubernetes.
|
||||
|
||||
From the beginning, Kubernetes has been able to run web-based workloads (containerized) really well. Workloads like web servers, Java, and associated app servers (PHP, Python, etc) just work. The supporting services like DNS, load balancing, and SSH (replaced by kubectl exec) are handled by the platform. For the majority of my career, these are the workloads I ran in production, so I immediately recognized the power of running production workloads with Kubernetes, aside from DevOps, aside from agile. There is incremental efficiency gain even if we barely change our cultural practices. Commissioning and decommissioning become extremely easy, which were terribly difficult with traditional IT. So, since the early days, Kubernetes has given me all of the basic primitives I need to model a production workload, in a single configuration language (Kube YAML/Json).
|
||||
|
||||
But, what happened if you needed to run Multi-master MySQL with replication? What about redundant data using Galera? How do you do snapshotting and backups? What about sophisticated workloads like SAP? Day zero (deployment) with simple applications (web servers, etc) has been fairly easy with Kubernetes, but day two operations and workloads were not tackled. That's not to say that day two operations with sophisticated workloads were harder than traditional IT to solve, but they weren't made easier with Kubernetes. Every user was left to devise their own genius ideas for solving these problems, which is basically the status quo today. Over the last 5 years, the number one type of question I get is around day two operations of complex workloads.
|
||||
|
||||
Thankfully, that's changing as we speak with the advent of Kubernetes Operators. With the advent of Operators, we now have a framework to codify day two operations knowledge into the platform. We can now apply the same defined state, actual state methodology that I described in [_Kubernetes basics: Learn how to drive first_][4]—we can now define, automate, and maintain a wide range of systems administration tasks.
|
||||
|
||||
I often refer to Operators as "Robot Sysadmins" because they essentially codify a bunch of the day two operations knowledge that a subject matter expert (SME, like database administrator or, systems administrator) for that workload type (database, web server, etc) would normally keep in their notes somewhere in a wiki. The problem with these notes being in a wiki is, for the knowledge to be applied to solve a problem, we need to:
|
||||
|
||||
1. Generate an event, often a monitoring system finds a fault and we create a ticket
|
||||
2. Human SME has to investigate the problem, even if it's something we've seen a million times before
|
||||
3. Human SME has to execute the knowledge (perform the backup/restore, configure the Galera or transaction replication, etc)
|
||||
|
||||
|
||||
|
||||
With Operators, all of this SME knowledge can be embedded in a separate container image which is deployed before the actual workload. We deploy the Operator container, and then the Operator deploys and manages one or more instances of the workload. We then manage the Operators using something like the Operator Lifecycle Manager (Katacoda tutorial).
|
||||
|
||||
So, as we move forward with Kubernetes, we not only simplify the deployment of applications, but also the management over the lifecycle. Operators also give us the tools to manage very complex, stateful applications with deep configuration requirements (clustering, replication, repair, backup/restore. And, the best part is, the people who built the container are probably the subject matter experts for day two operations, so now they can embed that knowledge into the operations environment.
|
||||
|
||||
### The conclusion to this series
|
||||
|
||||
The future of Kubernetes is bright, and like virtualization before it, workload expansion is inevitable. Learning how to drive Kubernetes is probably the biggest investment that a developer or sysadmin can make in their own career growth. As the workloads expand, so will the career opportunities. So, here's to driving an amazing [dump truck that's very elegant at moving dirt][2]...
|
||||
|
||||
If you would like to follow me on Twitter, I share a lot of content on this topic at [@fatherlinux][6]
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/19/6/kubernetes-potential-run-anything
|
||||
|
||||
作者：[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/fail_progress_cycle_momentum_arrow.png?itok=q-ZFa_Eh (arrows cycle symbol for failing faster)
|
||||
[2]: https://opensource.com/article/19/6/kubernetes-dump-truck
|
||||
[3]: https://opensource.com/article/19/6/kubernetes-learning-curve
|
||||
[4]: https://opensource.com/article/19/6/kubernetes-basics
|
||||
[5]: https://opensource.com/article/19/6/tools-drive-kubernetes
|
||||
[6]: https://twitter.com/fatherlinux
|
||||
@ -1,61 +0,0 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (Cloning a MAC address to bypass a captive portal)
|
||||
[#]: via: (https://fedoramagazine.org/cloning-a-mac-address-to-bypass-a-captive-portal/)
|
||||
[#]: author: (Esteban Wilson https://fedoramagazine.org/author/swilson/)
|
||||
|
||||
克隆 MAC 地址来绕过强制门户
|
||||
======
|
||||
|
||||
![][1]
|
||||
|
||||
如果你曾经不在家和办公室连接到 WiFi，那么通常会看到一个门户页面。它可能会要求你接受服务条款或其他协议才能访问。但是，当你无法通过这类门户进行连接时会发生什么？本文向你展示了如何在 Fedora 上使用 NetworkManager 处理某些故障情况，以便你仍然可以访问互联网。
|
||||
|
||||
### 强制门户如何工作
|
||||
|
||||
强制门户是新设备连接到网络时显示的网页。当用户首次访问互联网时，门户网站会捕获所有网页请求并将其重定向到单个门户页面。
|
||||
|
||||
然后，页面要求用户采取一些措施，通常是同意使用政策。用户同意后，他们可以向 RADIUS 或其他类型的身份验证系统进行身份验证。简而言之，强制门户根据设备的 MAC 地址和终端用户接受条款来注册和授权设备。 （MAC 地址是附加到任何网络接口（例如 WiFi 芯片或卡）的[基于硬件的值][2]。）
|
||||
|
||||
有时设备无法加载强制门户来进行身份验证和授权，以使用 WiFI 接入。这种情况的例子包括移动设备和游戏机（Switch，Playstation 等）。当连接到互联网时，它们通常不会打开动强制门户页面。连接到酒店或公共 WiFi 接入点时，你可能会看到这种情况。
|
||||
|
||||
不过，你可以在 Fedora 上使用 NetworkManager 来解决这些问题。Fedora 使你可以临时克隆连接设备的 MAC 地址，并代表该设备通过强制门户进行身份验证。你需要得到连接设备的 MAC 地址。通常，它被打印在设备上的某个地方并贴上标签。它是一个六字节的十六进制值，因此看起来类似 _4A:1A:4C:B0:38:1F_。通常，你也可以通过设备的内置菜单找到它。
|
||||
|
||||
### 使用 NetworkManager 克隆
|
||||
|
||||
首先，打开 _**nm-connection-editor**_，或通过”设置“打开 WiFi 设置。然后，你可以使用 NetworkManager 进行克隆：
|
||||
|
||||
* 对于以太网–选择已连接的以太网连接。然后选择 _Ethernet_ 选项卡。记录或复制当前的 MAC 地址。在 _Cloned MAC address_ 字段中输入游戏机或其他设备的 MAC 地址。
|
||||
* 对于 WiFi –选择 WiFi 配置名。然后选择 “WiFi” 选项卡。记录或复制当前的 MAC 地址。在 _Cloned MAC address_ 字段中输入游戏机或其他设备的 MAC 地址。
|
||||
|
||||
|
||||
|
||||
### **启动所需的设备**
|
||||
|
||||
当 Fedora 系统与以太网或 WiFi 配置连接，克隆的 MAC 地址将用于请求 IP 地址，并加载强制门户。输入所需的凭据和/或选择用户协议。MAC 地址将获得授权。
|
||||
|
||||
现在，断开 WiF i或以太网配置连接，然后将 Fedora 系统的 MAC 地址更改回其原始值。然后启动游戏机或其他设备。设备现在应该可以访问互联网了，因为它的网络接口已通过你的 Fedora 系统进行了授权。
|
||||
|
||||
不过，这不是 NetworkManager 全部能做的。例如，请参阅[随机化系统硬件地址][3]，来获得更好的隐私保护。
|
||||
|
||||
> [使用 NetworkManager 随机化你的 MAC 地址][3]
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://fedoramagazine.org/cloning-a-mac-address-to-bypass-a-captive-portal/
|
||||
|
||||
作者：[Esteban Wilson][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://fedoramagazine.org/author/swilson/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://fedoramagazine.org/wp-content/uploads/2019/10/clone-mac-nm-816x345.jpg
|
||||
[2]: https://en.wikipedia.org/wiki/MAC_address
|
||||
[3]: https://fedoramagazine.org/randomize-mac-address-nm/
|
||||
Loading…
Reference in New Issue
Block a user