mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-31 23:30:11 +08:00
commit
f17c3f0221
@ -1,24 +1,24 @@
|
|||||||
[#]: collector: (lujun9972)
|
[#]: collector: (lujun9972)
|
||||||
[#]: translator: (HankChow)
|
[#]: translator: (HankChow)
|
||||||
[#]: reviewer: ( )
|
[#]: reviewer: (wxy)
|
||||||
[#]: publisher: ( )
|
[#]: publisher: (wxy)
|
||||||
[#]: url: ( )
|
[#]: url: (https://linux.cn/article-10717-1.html)
|
||||||
[#]: subject: (Using Square Brackets in Bash: Part 1)
|
[#]: subject: (Using Square Brackets in Bash: Part 1)
|
||||||
[#]: via: (https://www.linux.com/blog/2019/3/using-square-brackets-bash-part-1)
|
[#]: via: (https://www.linux.com/blog/2019/3/using-square-brackets-bash-part-1)
|
||||||
[#]: author: (Paul Brown https://www.linux.com/users/bro66)
|
[#]: author: (Paul Brown https://www.linux.com/users/bro66)
|
||||||
|
|
||||||
在 Bash 中使用方括号 [第 1 节]
|
在 Bash 中使用[方括号] (一)
|
||||||
======
|
======
|
||||||
|
|
||||||
![square brackets][1]
|
![square brackets][1]
|
||||||
|
|
||||||
> 这篇文章将要介绍方括号及其在命令行中的用法。
|
> 这篇文章将要介绍方括号及其在命令行中的不同用法。
|
||||||
|
|
||||||
看完[花括号在命令行中的用法][3]之后,现在我们继续来看方括号(`[]`)在上下文中是如何发挥作用的。
|
看完[花括号在命令行中的用法][3]之后,现在我们继续来看方括号(`[]`)在上下文中是如何发挥作用的。
|
||||||
|
|
||||||
### <ruby>通配<rt>Globbing</rt></ruby>
|
### 通配
|
||||||
|
|
||||||
方括号最简单的用法就是通配。你可能在知道“通配”这个概念之前就已经通过通配来匹配内容了,列出具有相同特征的多个文件就是一个很常见的场景,例如列出所有 JPEG 文件:
|
方括号最简单的用法就是通配。你可能在知道“<ruby><rt>Globbing</rt></ruby>”这个概念之前就已经通过通配来匹配内容了,列出具有相同特征的多个文件就是一个很常见的场景,例如列出所有 JPEG 文件:
|
||||||
|
|
||||||
```
|
```
|
||||||
ls *.jpg
|
ls *.jpg
|
||||||
@ -70,7 +70,7 @@ ls file0[259][278]
|
|||||||
cp file0[12]? archive0[12]?
|
cp file0[12]? archive0[12]?
|
||||||
```
|
```
|
||||||
|
|
||||||
因为通配只能针对已有的文件,而 archive 开头的文件并不存在,不能进行通配。
|
因为通配只能针对已有的文件,而 `archive` 开头的文件并不存在,不能进行通配。
|
||||||
|
|
||||||
而这条命令
|
而这条命令
|
||||||
|
|
||||||
@ -82,7 +82,6 @@ cp file0[12]? archive0[1..2][0..9]
|
|||||||
|
|
||||||
```
|
```
|
||||||
mkdir archive
|
mkdir archive
|
||||||
|
|
||||||
cp file0[12]? archive
|
cp file0[12]? archive
|
||||||
```
|
```
|
||||||
|
|
||||||
@ -94,7 +93,6 @@ cp file0[12]? archive
|
|||||||
|
|
||||||
```
|
```
|
||||||
myvar="Hello World"
|
myvar="Hello World"
|
||||||
|
|
||||||
echo Goodbye Cruel ${myvar#Hello}
|
echo Goodbye Cruel ${myvar#Hello}
|
||||||
```
|
```
|
||||||
|
|
||||||
@ -104,11 +102,8 @@ echo Goodbye Cruel ${myvar#Hello}
|
|||||||
|
|
||||||
```
|
```
|
||||||
for i in file0[12]?;\
|
for i in file0[12]?;\
|
||||||
|
|
||||||
do\
|
do\
|
||||||
|
|
||||||
cp $i archive${i#file};\
|
cp $i archive${i#file};\
|
||||||
|
|
||||||
done
|
done
|
||||||
```
|
```
|
||||||
|
|
||||||
@ -120,7 +115,7 @@ done
|
|||||||
"archive" + "file019" - "file" = "archive019"
|
"archive" + "file019" - "file" = "archive019"
|
||||||
```
|
```
|
||||||
|
|
||||||
最终整个 `cp` 命令是这样的:
|
最终整个 `cp` 命令展开为:
|
||||||
|
|
||||||
```
|
```
|
||||||
cp file019 archive019
|
cp file019 archive019
|
||||||
@ -137,7 +132,7 @@ via: https://www.linux.com/blog/2019/3/using-square-brackets-bash-part-1
|
|||||||
作者:[Paul Brown][a]
|
作者:[Paul Brown][a]
|
||||||
选题:[lujun9972][b]
|
选题:[lujun9972][b]
|
||||||
译者:[HankChow](https://github.com/HankChow)
|
译者:[HankChow](https://github.com/HankChow)
|
||||||
校对:[校对者ID](https://github.com/校对者ID)
|
校对:[wxy](https://github.com/wxy)
|
||||||
|
|
||||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
|
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
|
||||||
|
|
||||||
@ -145,5 +140,5 @@ via: https://www.linux.com/blog/2019/3/using-square-brackets-bash-part-1
|
|||||||
[b]: https://github.com/lujun9972
|
[b]: https://github.com/lujun9972
|
||||||
[1]: https://www.linux.com/sites/lcom/files/styles/rendered_file/public/square-gabriele-diwald-475007-unsplash.jpg?itok=cKmysLfd "square brackets"
|
[1]: https://www.linux.com/sites/lcom/files/styles/rendered_file/public/square-gabriele-diwald-475007-unsplash.jpg?itok=cKmysLfd "square brackets"
|
||||||
[2]: https://www.linux.com/LICENSES/CATEGORY/CREATIVE-COMMONS-ZERO
|
[2]: https://www.linux.com/LICENSES/CATEGORY/CREATIVE-COMMONS-ZERO
|
||||||
[3]: https://www.linux.com/blog/learn/2019/2/all-about-curly-braces-bash
|
[3]: https://linux.cn/article-10624-1.html
|
||||||
|
|
@ -1,3 +1,5 @@
|
|||||||
|
translating by MjSeven
|
||||||
|
|
||||||
Getting started with Sensu monitoring
|
Getting started with Sensu monitoring
|
||||||
======
|
======
|
||||||
![](https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/rh_003601_05_mech_osyearbook2016_cloud_cc.png?itok=XSV7yR9e)
|
![](https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/rh_003601_05_mech_osyearbook2016_cloud_cc.png?itok=XSV7yR9e)
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
[#]: collector: (lujun9972)
|
[#]: collector: (lujun9972)
|
||||||
[#]: translator: ( )
|
[#]: translator: (HankChow)
|
||||||
[#]: reviewer: ( )
|
[#]: reviewer: ( )
|
||||||
[#]: publisher: ( )
|
[#]: publisher: ( )
|
||||||
[#]: url: ( )
|
[#]: url: ( )
|
||||||
|
135
sources/tech/20190411 Be your own certificate authority.md
Normal file
135
sources/tech/20190411 Be your own certificate authority.md
Normal file
@ -0,0 +1,135 @@
|
|||||||
|
[#]: collector: (lujun9972)
|
||||||
|
[#]: translator: ( )
|
||||||
|
[#]: reviewer: ( )
|
||||||
|
[#]: publisher: ( )
|
||||||
|
[#]: url: ( )
|
||||||
|
[#]: subject: (Be your own certificate authority)
|
||||||
|
[#]: via: (https://opensource.com/article/19/4/certificate-authority)
|
||||||
|
[#]: author: (Moshe Zadka (Community Moderator) https://opensource.com/users/moshez/users/elenajon123)
|
||||||
|
|
||||||
|
Be your own certificate authority
|
||||||
|
======
|
||||||
|
Create a simple, internal CA for your microservice architecture or
|
||||||
|
integration testing.
|
||||||
|
![][1]
|
||||||
|
|
||||||
|
The Transport Layer Security ([TLS][2]) model, which is sometimes referred to by the older name SSL, is based on the concept of [certificate authorities][3] (CAs). These authorities are trusted by browsers and operating systems and, in turn, _sign_ servers' certificates to validate their ownership.
|
||||||
|
|
||||||
|
However, for an intranet, a microservice architecture, or integration testing, it is sometimes useful to have a _local CA_ : one that is trusted only internally and, in turn, signs local servers' certificates.
|
||||||
|
|
||||||
|
This especially makes sense for integration tests. Getting certificates can be a burden because the servers will be up for minutes. But having an "ignore certificate" option in the code could allow it to be activated in production, leading to a security catastrophe.
|
||||||
|
|
||||||
|
A CA certificate is not much different from a regular server certificate; what matters is that it is trusted by local code. For example, in the **requests** library, this can be done by setting the **REQUESTS_CA_BUNDLE** variable to a directory containing this certificate.
|
||||||
|
|
||||||
|
In the example of creating a certificate for integration tests, there is no need for a _long-lived_ certificate: if your integration tests take more than a day, you have already failed.
|
||||||
|
|
||||||
|
So, calculate **yesterday** and **tomorrow** as the validity interval:
|
||||||
|
|
||||||
|
|
||||||
|
```
|
||||||
|
>>> import datetime
|
||||||
|
>>> one_day = datetime.timedelta(days=1)
|
||||||
|
>>> today = datetime.date.today()
|
||||||
|
>>> yesterday = today - one_day
|
||||||
|
>>> tomorrow = today - one_day
|
||||||
|
```
|
||||||
|
|
||||||
|
Now you are ready to create a simple CA certificate. You need to generate a private key, create a public key, set up the "parameters" of the CA, and then self-sign the certificate: a CA certificate is _always_ self-signed. Finally, write out both the certificate file as well as the private key file.
|
||||||
|
|
||||||
|
|
||||||
|
```
|
||||||
|
from cryptography.hazmat.primitives.asymmetric import rsa
|
||||||
|
from cryptography.hazmat.primitives import hashes, serialization
|
||||||
|
from cryptography import x509
|
||||||
|
from cryptography.x509.oid import NameOID
|
||||||
|
|
||||||
|
private_key = rsa.generate_private_key(
|
||||||
|
public_exponent=65537,
|
||||||
|
key_size=2048,
|
||||||
|
backend=default_backend()
|
||||||
|
)
|
||||||
|
public_key = private_key.public_key()
|
||||||
|
builder = x509.CertificateBuilder()
|
||||||
|
builder = builder.subject_name(x509.Name([
|
||||||
|
x509.NameAttribute(NameOID.COMMON_NAME, 'Simple Test CA'),
|
||||||
|
]))
|
||||||
|
builder = builder.issuer_name(x509.Name([
|
||||||
|
x509.NameAttribute(NameOID.COMMON_NAME, 'Simple Test CA'),
|
||||||
|
]))
|
||||||
|
builder = builder.not_valid_before(yesterday)
|
||||||
|
builder = builder.not_valid_after(tomorrow)
|
||||||
|
builder = builder.serial_number(x509.random_serial_number())
|
||||||
|
builder = builder.public_key(public_key)
|
||||||
|
builder = builder.add_extension(
|
||||||
|
x509.BasicConstraints(ca=True, path_length=None),
|
||||||
|
critical=True)
|
||||||
|
certificate = builder.sign(
|
||||||
|
private_key=private_key, algorithm=hashes.SHA256(),
|
||||||
|
backend=default_backend()
|
||||||
|
)
|
||||||
|
private_bytes = private_key.private_bytes(
|
||||||
|
encoding=serialization.Encoding.PEM,
|
||||||
|
format=serialization.PrivateFormat.TraditionalOpenSSL,
|
||||||
|
encryption_algorithm=serialization.NoEncrption())
|
||||||
|
public_bytes = certificate.public_bytes(
|
||||||
|
encoding=serialization.Encoding.PEM)
|
||||||
|
with open("ca.pem", "wb") as fout:
|
||||||
|
fout.write(private_bytes + public_bytes)
|
||||||
|
with open("ca.crt", "wb") as fout:
|
||||||
|
fout.write(public_bytes)
|
||||||
|
```
|
||||||
|
|
||||||
|
In general, a real CA will expect a [certificate signing request][4] (CSR) to sign a certificate. However, when you are your own CA, you can make your own rules! Just go ahead and sign what you want.
|
||||||
|
|
||||||
|
Continuing with the integration test example, you can create the private keys and sign the corresponding public keys right then. Notice **COMMON_NAME** needs to be the "server name" in the **https** URL. If you've configured name lookup, the needed server will respond on **service.test.local**.
|
||||||
|
|
||||||
|
|
||||||
|
```
|
||||||
|
service_private_key = rsa.generate_private_key(
|
||||||
|
public_exponent=65537,
|
||||||
|
key_size=2048,
|
||||||
|
backend=default_backend()
|
||||||
|
)
|
||||||
|
service_public_key = service_private_key.public_key()
|
||||||
|
builder = x509.CertificateBuilder()
|
||||||
|
builder = builder.subject_name(x509.Name([
|
||||||
|
x509.NameAttribute(NameOID.COMMON_NAME, 'service.test.local')
|
||||||
|
]))
|
||||||
|
builder = builder.not_valid_before(yesterday)
|
||||||
|
builder = builder.not_valid_after(tomorrow)
|
||||||
|
builder = builder.public_key(public_key)
|
||||||
|
certificate = builder.sign(
|
||||||
|
private_key=private_key, algorithm=hashes.SHA256(),
|
||||||
|
backend=default_backend()
|
||||||
|
)
|
||||||
|
private_bytes = service_private_key.private_bytes(
|
||||||
|
encoding=serialization.Encoding.PEM,
|
||||||
|
format=serialization.PrivateFormat.TraditionalOpenSSL,
|
||||||
|
encryption_algorithm=serialization.NoEncrption())
|
||||||
|
public_bytes = certificate.public_bytes(
|
||||||
|
encoding=serialization.Encoding.PEM)
|
||||||
|
with open("service.pem", "wb") as fout:
|
||||||
|
fout.write(private_bytes + public_bytes)
|
||||||
|
```
|
||||||
|
|
||||||
|
Now the **service.pem** file has a private key and a certificate that is "valid": it has been signed by your local CA. The file is in a format that can be given to, say, Nginx, HAProxy, or most other HTTPS servers.
|
||||||
|
|
||||||
|
By applying this logic to testing scripts, it's easy to create servers that look like authentic HTTPS servers, as long as the client is configured to trust the right CA.
|
||||||
|
|
||||||
|
--------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
via: https://opensource.com/article/19/4/certificate-authority
|
||||||
|
|
||||||
|
作者:[Moshe Zadka (Community Moderator)][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/moshez/users/elenajon123
|
||||||
|
[b]: https://github.com/lujun9972
|
||||||
|
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/rh_commun_4604_02_mech_connections_rhcz0.5x.png?itok=YPPU4dMj
|
||||||
|
[2]: https://en.wikipedia.org/wiki/Transport_Layer_Security
|
||||||
|
[3]: https://en.wikipedia.org/wiki/Certificate_authority
|
||||||
|
[4]: https://en.wikipedia.org/wiki/Certificate_signing_request
|
@ -0,0 +1,73 @@
|
|||||||
|
[#]: collector: (lujun9972)
|
||||||
|
[#]: translator: ( )
|
||||||
|
[#]: reviewer: ( )
|
||||||
|
[#]: publisher: ( )
|
||||||
|
[#]: url: ( )
|
||||||
|
[#]: subject: (How do you contribute to open source without code?)
|
||||||
|
[#]: via: (https://opensource.com/article/19/4/contribute-without-code)
|
||||||
|
[#]: author: (Chris Hermansen (Community Moderator) https://opensource.com/users/clhermansen/users/don-watkins/users/greg-p/users/petercheer)
|
||||||
|
|
||||||
|
How do you contribute to open source without code?
|
||||||
|
======
|
||||||
|
|
||||||
|
![Dandelion held out over water][1]
|
||||||
|
|
||||||
|
My earliest open source contributions date back to the mid-1980s when our organization first connected to [UseNet][2] where we discovered the contributed code and the opportunities to share in its development and support.
|
||||||
|
|
||||||
|
Today there are endless contribution opportunities, from contributing code to making how-to videos.
|
||||||
|
|
||||||
|
I'm going to step right over the whole issue of contributing code, other than pointing out that many of us who write code but don't consider ourselves developers can still [contribute code][3]. Instead, I'd like to remind everyone that there are lots of [non-code ways to contribute to open source][4] and talk about three alternatives.
|
||||||
|
|
||||||
|
### Filing bug reports
|
||||||
|
|
||||||
|
One important and concrete kind of contribution could best be described as "not being afraid to file a decent bug report" and [all the consequences related to that][5]. Sometimes it's quite challenging to [file a decent bug report][6]. For example:
|
||||||
|
|
||||||
|
* A bug may be difficult to record or describe. A long and complicated message with all sorts of unrecognizable codes may flash by as the computer is booting, or there may just be some "odd behavior" on the screen with no error messages produced.
|
||||||
|
* A bug may be difficult to reproduce. It may occur only on certain hardware/software configurations, or it may be rarely triggered, or the precise problem area may not be apparent.
|
||||||
|
* A bug may be linked to a very specific development environment configuration that is too big, messy, and complicated to share, requiring laborious creation of a stripped-down example.
|
||||||
|
* When reporting a bug to a distro, the maintainers may suggest filing the bug upstream instead, which can sometimes lead to a lot of work when the version supported by the distro is not the primary version of interest to the upstream community. (This can happen when the version provided in the distro lags the officially supported release and development version.)
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Nevertheless, I exhort would-be bug reporters (including me) to press on and try to get bugs fully recorded and acknowledged.
|
||||||
|
|
||||||
|
One way to get started is to use your favorite search tool to look for similar bug reports, see how they are described, where they are filed, and so on. Another important thing to know is the formal mechanism defined for bug reporting by your distro (for example, [Fedora's is here][7]; [openSUSE's is here][8]; [Ubuntu's is here][9]) or software package ([LibreOffice's is here][10]; [Mozilla's seems to be here][11]).
|
||||||
|
|
||||||
|
### Answering user's questions
|
||||||
|
|
||||||
|
I lurk and occasionally participate in various mailing lists and forums, such as the [Ubuntu quality control team][12] and [forums][13], [LinuxQuestions.org][14], and the [ALSA users' mailing list][15]. Here, the contributions may relate less to bugs and more to documenting complex use cases. It's a great feeling for everyone to see someone jumping in to help a person sort out their trouble with a particular issue.
|
||||||
|
|
||||||
|
### Writing about open source
|
||||||
|
|
||||||
|
Finally, another area where I really enjoy contributing is [_writing_][16] about using open source software; whether it's a how-to guide, a comparative evaluation of different solutions to a particular problem, or just generally exploring an area of interest (in my case, using open source music-playing software to enjoy music). A similar option is making an instructional video; it's easy to [record the desktop][17] while demonstrating some fiendishly difficult desktop maneuver, such as creating a splashy logo with GIMP. And those of you who are bi- or multi-lingual can also consider translating existing how-to articles or videos to another language.
|
||||||
|
|
||||||
|
--------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
via: https://opensource.com/article/19/4/contribute-without-code
|
||||||
|
|
||||||
|
作者:[Chris Hermansen (Community Moderator)][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/clhermansen/users/don-watkins/users/greg-p/users/petercheer
|
||||||
|
[b]: https://github.com/lujun9972
|
||||||
|
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/dandelion_blue_water_hand.jpg?itok=QggW8Wnw (Dandelion held out over water)
|
||||||
|
[2]: https://en.wikipedia.org/wiki/Usenet
|
||||||
|
[3]: https://opensource.com/article/19/2/open-science-git
|
||||||
|
[4]: https://opensource.com/life/16/1/8-ways-contribute-open-source-without-writing-code
|
||||||
|
[5]: https://producingoss.com/en/bug-tracker.html
|
||||||
|
[6]: https://opensource.com/article/19/3/bug-reporting
|
||||||
|
[7]: https://docs.fedoraproject.org/en-US/quick-docs/howto-file-a-bug/
|
||||||
|
[8]: https://en.opensuse.org/openSUSE:Submitting_bug_reports
|
||||||
|
[9]: https://help.ubuntu.com/stable/ubuntu-help/report-ubuntu-bug.html.en
|
||||||
|
[10]: https://wiki.documentfoundation.org/QA/BugReport
|
||||||
|
[11]: https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines
|
||||||
|
[12]: https://wiki.ubuntu.com/QATeam
|
||||||
|
[13]: https://ubuntuforums.org/
|
||||||
|
[14]: https://www.linuxquestions.org/
|
||||||
|
[15]: https://www.alsa-project.org/wiki/Mailing-lists
|
||||||
|
[16]: https://opensource.com/users/clhermansen
|
||||||
|
[17]: https://opensource.com/education/16/10/simplescreenrecorder-and-kazam
|
@ -0,0 +1,135 @@
|
|||||||
|
[#]: collector: (lujun9972)
|
||||||
|
[#]: translator: ( )
|
||||||
|
[#]: reviewer: ( )
|
||||||
|
[#]: publisher: ( )
|
||||||
|
[#]: url: ( )
|
||||||
|
[#]: subject: (Installing Ubuntu MATE on a Raspberry Pi)
|
||||||
|
[#]: via: (https://itsfoss.com/ubuntu-mate-raspberry-pi/)
|
||||||
|
[#]: author: (Chinmay https://itsfoss.com/author/chinmay/)
|
||||||
|
|
||||||
|
Installing Ubuntu MATE on a Raspberry Pi
|
||||||
|
======
|
||||||
|
|
||||||
|
_**Brief: This quick tutorial shows you how to install Ubuntu MATE on Raspberry Pi devices.**_
|
||||||
|
|
||||||
|
[Raspberry Pi][1] is by far the most popular SBC (Single Board Computer) and the go-to board for makers. [Raspbian][2] which is based on Debian is the official operating system for the Pi. It is lightweight, comes bundled with educational tools and gets the job done for most scenarios.
|
||||||
|
|
||||||
|
[Installing Raspbian][3] is easy as well but the problem with [Debian][4] is its slow upgrade cycles and older packages.
|
||||||
|
|
||||||
|
Running Ubuntu on the Raspberry Pi gives you a richer experience and up to date software. We have a few options when it comes to running Ubuntu on your Pi.
|
||||||
|
|
||||||
|
1. [Ubuntu MATE][5] : Ubuntu MATE is the only distribution which natively supports the Raspberry Pi with a complete desktop environment.
|
||||||
|
2. [Ubuntu Server 18.04][6] \+ Installing a desktop environment manually.
|
||||||
|
3. Using Images built by the [Ubuntu Pi Flavor Maker][7] community, _these images only support the Raspberry Pi 2B and 3B variants_ and are **not** updated to the latest LTS release.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
The first option is the easiest and the quickest to set up while the second option gives you the freedom to install the desktop environment of your choice. I recommend going with either of the first two options.
|
||||||
|
|
||||||
|
Here are the links to download the Disc Images. In this article I’ll be covering Ubuntu MATE installation only.
|
||||||
|
|
||||||
|
### Installing Ubuntu MATE on Raspberry Pi
|
||||||
|
|
||||||
|
Go to the download page of Ubuntu MATE and get the recommended images.
|
||||||
|
|
||||||
|
![][8]
|
||||||
|
|
||||||
|
The experimental ARM64 version should only be used if you need to run 64-bit only applications like MongoDB on a Raspberry Pi server.
|
||||||
|
|
||||||
|
[Download Ubuntu MATE for Raspberry Pi][9]
|
||||||
|
|
||||||
|
#### Step 1: Setting Up the SD Card
|
||||||
|
|
||||||
|
The image file needs to be decompressed once downloaded. You can simply right click on it to extract it.
|
||||||
|
|
||||||
|
Alternatively, the following command will do the job.
|
||||||
|
|
||||||
|
```
|
||||||
|
xz -d ubuntu-mate***.img.xz
|
||||||
|
```
|
||||||
|
|
||||||
|
Alternatively you can use [7-zip][10] if you are on Windows.
|
||||||
|
|
||||||
|
Install **[Balena Etcher][11]** , we’ll use this tool to write the image to the SD card. Make sure that your SD card is at least 8 GB capacity.
|
||||||
|
|
||||||
|
Launch Etcher and select the image file and your SD card.
|
||||||
|
|
||||||
|
![][12]
|
||||||
|
|
||||||
|
Once the flashing process is complete the SD card is ready.
|
||||||
|
|
||||||
|
#### Step 2: Setting Up the Raspberry Pi
|
||||||
|
|
||||||
|
You probably already know that you need a few things to get started with Raspberry Pi such as a mouse, keyboard, HDMI cable etc. You can also [install Raspberry Pi headlessly without keyboard and mouse][13] but this tutorial is not about that.
|
||||||
|
|
||||||
|
* Plug in a mouse and a keyboard.
|
||||||
|
* Connect the HDMI cable.
|
||||||
|
* Insert the SD card into the SD card slot.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Power it on by plugging in the power cable. Make sure you have a good power supply (5V, 3A minimum). A bad power supply can reduce the performance.
|
||||||
|
|
||||||
|
#### Ubuntu MATE installation
|
||||||
|
|
||||||
|
Once you power on the Raspberry Pi, you’ll be greeted with a very familiar Ubuntu installation process. The process is pretty much straight forward from here.
|
||||||
|
|
||||||
|
![Select your keyboard layout][14]
|
||||||
|
|
||||||
|
![Select Your Timezone][15]
|
||||||
|
|
||||||
|
Select your WiFi network and enter the password in the network connection screen.
|
||||||
|
|
||||||
|
![Add Username and Password][16]
|
||||||
|
|
||||||
|
After setting the keyboard layout, timezone and user credentials you’ll be taken to the login screen after a few minutes. And voila! you are almost done.
|
||||||
|
|
||||||
|
![][17]
|
||||||
|
|
||||||
|
Once logged in, the first thing you should do is to [update Ubuntu][18]. You can use the command line for that.
|
||||||
|
|
||||||
|
```
|
||||||
|
sudo apt update
|
||||||
|
sudo apt upgrade
|
||||||
|
```
|
||||||
|
|
||||||
|
You can also use the Software Updater.
|
||||||
|
|
||||||
|
![][19]
|
||||||
|
|
||||||
|
Once the updates are finished installing you are good to go. You can also go ahead and install Raspberry Pi specific packages for GPIO and other I/O depending on your needs.
|
||||||
|
|
||||||
|
What made you think about installing Ubuntu on the Raspberry and how has your experience been with Raspbian? Let me know in the comments below.
|
||||||
|
|
||||||
|
--------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
via: https://itsfoss.com/ubuntu-mate-raspberry-pi/
|
||||||
|
|
||||||
|
作者:[Chinmay][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://itsfoss.com/author/chinmay/
|
||||||
|
[b]: https://github.com/lujun9972
|
||||||
|
[1]: https://www.raspberrypi.org/
|
||||||
|
[2]: https://www.raspberrypi.org/downloads/
|
||||||
|
[3]: https://itsfoss.com/tutorial-how-to-install-raspberry-pi-os-raspbian-wheezy/
|
||||||
|
[4]: https://www.debian.org/
|
||||||
|
[5]: https://ubuntu-mate.org/
|
||||||
|
[6]: https://wiki.ubuntu.com/ARM/RaspberryPi#Recovering_a_system_using_the_generic_kernel
|
||||||
|
[7]: https://ubuntu-pi-flavour-maker.org/download/
|
||||||
|
[8]: https://i0.wp.com/itsfoss.com/wp-content/uploads/2019/04/ubuntu-mate-raspberry-pi-download.jpg?ssl=1
|
||||||
|
[9]: https://ubuntu-mate.org/download/
|
||||||
|
[10]: https://www.7-zip.org/download.html
|
||||||
|
[11]: https://www.balena.io/etcher/
|
||||||
|
[12]: https://i0.wp.com/itsfoss.com/wp-content/uploads/2019/04/Screenshot-from-2019-04-08-01-36-16.png?ssl=1
|
||||||
|
[13]: https://linuxhandbook.com/raspberry-pi-headless-setup/
|
||||||
|
[14]: https://i2.wp.com/itsfoss.com/wp-content/uploads/2019/04/Keyboard-layout-ubuntu.jpg?fit=800%2C467&ssl=1
|
||||||
|
[15]: https://i2.wp.com/itsfoss.com/wp-content/uploads/2019/04/select-time-zone-ubuntu.jpg?fit=800%2C468&ssl=1
|
||||||
|
[16]: https://i2.wp.com/itsfoss.com/wp-content/uploads/2019/04/Credentials-ubuntu.jpg?fit=800%2C469&ssl=1
|
||||||
|
[17]: https://i2.wp.com/itsfoss.com/wp-content/uploads/2019/04/Desktop-ubuntu.jpg?fit=800%2C600&ssl=1
|
||||||
|
[18]: https://itsfoss.com/update-ubuntu/
|
||||||
|
[19]: https://i1.wp.com/itsfoss.com/wp-content/uploads/2019/04/update-software.png?ssl=1
|
@ -0,0 +1,103 @@
|
|||||||
|
[#]: collector: (lujun9972)
|
||||||
|
[#]: translator: ( )
|
||||||
|
[#]: reviewer: ( )
|
||||||
|
[#]: publisher: ( )
|
||||||
|
[#]: url: ( )
|
||||||
|
[#]: subject: (Managed, enabled, empowered: 3 dimensions of leadership in an open organization)
|
||||||
|
[#]: via: (https://opensource.com/open-organization/19/4/managed-enabled-empowered)
|
||||||
|
[#]: author: (Heidi Hess von Ludewig (Red Hat) https://opensource.com/users/heidi-hess-von-ludewig/users/amatlack)
|
||||||
|
|
||||||
|
Managed, enabled, empowered: 3 dimensions of leadership in an open organization
|
||||||
|
======
|
||||||
|
Different types of work call for different types of engagement. Should
|
||||||
|
open leaders always aim for empowerment?
|
||||||
|
![][1]
|
||||||
|
|
||||||
|
"Empowerment" seems to be the latest people management [buzzword][2]. And it's an important consideration for open organizations, too. After all, we like to think these open organizations thrive when the people inside them are equipped to take initiative to do their best work as they see fit. Shouldn't an open leader's goal be complete and total empowerment of everyone, in all parts of the organization, doing all types of work?
|
||||||
|
|
||||||
|
Not necessarily.
|
||||||
|
|
||||||
|
Before we jump on the employee [empowerment bandwagon][3], we should explore the important connections between empowerment and innovation. That requires placing empowerment in context.
|
||||||
|
|
||||||
|
As Allison Matlack has already demonstrated, employee investment in an organization's mission and activities—and employee _autonomy_ relative to those things—[can take several forms][4], from "managed" to "enabled" to "empowered." Sometimes, complete and total empowerment _isn't_ the most desirable type of investment an open leader would like to activate in a contributor. Projects are always changing. New challenges are always arising. As a result, the _type_ or _degree_ of involvement leaders can expect in different situations is always shifting. "Managed," "enabled," and "empowered," contributors exist simultaneously and dynamically, depending on the work they're performing (and that work's desired outcomes).
|
||||||
|
|
||||||
|
So before we head down to the community center to win a game of buzzword bingo, let's examine the different types of work, how they function, and how they contribute to the overall innovation of a company. Let's refine what we mean by "managed," "enabled," and "empowered" work, and discuss why we need all three.
|
||||||
|
|
||||||
|
### Managed, enabled, empowered
|
||||||
|
|
||||||
|
First, let's consider and define each type of work activity.
|
||||||
|
|
||||||
|
"Managed" work involves tasks that are coordinated using guidance, supervision, and direction in order to achieve specific outcomes. When someone works to coordinate _every_ part of _every_ task, we colloquially call that behavior "micro-managing." "Enabled" associates have the ability to direct themselves while working within boundaries (guidance), and they have access to the materials and resources (information, people, technologies, etc.) they require to problem-solve as they see fit. Lastly, "empowered" individuals _direct themselves_ within organizational limits, have access materials and resources, and also have the authority to represent their team or organization and make decisions about work on behalf using their best judgement, based on the former elements.
|
||||||
|
|
||||||
|
Most important here is the idea that these concepts are _nested_ (see Figure 1). Because each level builds on the one before it, one cannot have the full benefit of "empowered" associates without also having clear guidance and direction ("managed"), and transparency of information and resources ("enabled"). What changes from level to level is the amount of managed or enabled activity that comes before it.
|
||||||
|
|
||||||
|
Let's dive more deeply into the nature of those activities and discuss the roles leaders should play in each.
|
||||||
|
|
||||||
|
#### Managed work
|
||||||
|
|
||||||
|
"Managed" work is just that: work activity supervised and directed to some degree. The amount of management occurring in a situation is dynamic and depends on the activity itself. For instance, in the manufacturing economy, managed work is prominent. I'll call this "widget" work, the point of which is producing a widget the same way, every time. People need to perform this work according to consistent processes with consistent, standardized outcomes.
|
||||||
|
|
||||||
|
Before we jump on the employee empowerment bandwagon, we should explore the important connections between empowerment and innovation. That requires placing empowerment in context.
|
||||||
|
|
||||||
|
Because this work requires consistency, it typically proceeds via explicit guidelines and policies (rules about cost, schedule, quality, quantity, process, and so on—characteristics applicable to all work to a greater or lesser degree). We can find examples of it in a variety of roles across many industries. Quite often, _any_ role in _any_ industry requires _some_ amount of this type of work. Examples include manufacturing precision machine parts, answering a customer support case within a specified timeframe for contractual reasons and with a friendly greeting, etc. In the software industry, a role that's _entirely_ like this would be a rarity, yet even these roles require some work of the "managed" type. For instance, consider the way a support engineer must respond to a case using a set of quality standards (friendliness, perhaps with a professional written tone, a branded signature line, adherence to a participat contractual agreement, usually responding within a particular time frame, etc.).
|
||||||
|
|
||||||
|
"Management" is the best strategy when _work requirements include adhering to a consistent schedule, process, and quality._
|
||||||
|
|
||||||
|
#### Enabled work
|
||||||
|
|
||||||
|
As the amount of creativity a role requires _increases_ , the amount of directed and "managed" work we find in that role _decreases_. Guidelines get broader, processes looser, schedules lengthened (I wish!). This is because what's required to "be creative" involves other types of work (and new degrees of transparency and authority along with them). Ron McFarland explains this in [his article on adaptive leadership][5]: Many challenges challenges are ambiguous, as opposed to technical, and therefore require specific kinds of leadership.
|
||||||
|
|
||||||
|
To take this idea one step further, we might say open leaders need to be _adaptive_ to how they view and implement the different kinds of work on their teams or in their organizations. "Enabling" associates means growing their skills and knowledge so they can manage themselves. The foundation for this type of activity is information—access to it, sharing it, and opportunities to independently use it to complete work activity. This is the kind of work Peter Drucker was referring to when he coined the term "knowledge work."
|
||||||
|
|
||||||
|
Enabled work liberates associates from the constraints of managed work, though it still involves leaders providing considerable direction and guidance. Outcomes of this work might be familiar and normalized, but the _paths to achieving them_ are more open-ended than in managed work. Methods are more flexible and inclusive of individual preference and capability.
|
||||||
|
|
||||||
|
"Enablement" is the best strategy when _objectives are well-defined and the outcomes are aligned with past outcomes and results_.
|
||||||
|
|
||||||
|
#### Empowered work
|
||||||
|
|
||||||
|
In "[Beyond Engagement][4]," Allison describes empowerment as a state in which employees have "access to all the information, training, tools, and connections to people and others teams that they need to do their best work, as well as a safe environment in which to do that work so they feel comfortable making their own decisions." In other words, empowerment is enablement with the opportunity for associates to _act using their own best judgment as it relates to shared understanding of team and organizational guidelines and objectives._
|
||||||
|
|
||||||
|
"Empowerment" is the best strategy when _objectives and methods for achieving them are unclear and creative flexibility is necessary for defining them._ Often this work is focused on activities where problem definition and possible solutions (i.e. investigation, planning, and execution) are not well-defined.
|
||||||
|
|
||||||
|
Any role in any organization involves these three types of work occurring at various moments and in various situations. No job requires just one.
|
||||||
|
|
||||||
|
### Supporting innovation through managed, enabled, and empowered work
|
||||||
|
|
||||||
|
The labels "managed," enabled," and "empowered" apply to different work at different times, and _all three_ are embedded in work activity at different times and in different tasks. That means leaders should be paying more attention to the work contributors are doing: the kind of work, its purpose, and its desired outcomes. We're now in a position to consider how _innovation_ factors into this equation.
|
||||||
|
|
||||||
|
Frequently, people discuss the different modes of work by way of _contrast_. Most language about them connotes negativity: managed work is "the worst," while empowered work is "the best." The goal of any leadership practice should be to "move people along the scale"—to create empowered contributors.
|
||||||
|
|
||||||
|
However, just as types of work are located on a continuum that doesn't include this element of negation, so too should our understanding of the types of work. Rather than seeing work as, for example " _always empowered"_ or _"always managed_ ," we should recognize that any role is a function of _of all three types of work at the same time_ , each to a varying degree. Think of the equation this way:
|
||||||
|
|
||||||
|
> _Work = managed (x) + enabled (x) + empowered (x)_
|
||||||
|
|
||||||
|
Note here that the more enabled and empowered the work is, the more potential there is for creativity when doing that work. This is because creativity (and the creative individual) requires information—consistently updated and "fresh" sources of information—used in conjunction with individual judgment and capacity for interpreting how to _use_ and _combine_ that information to define problems, ideate, and solve problems. Enabled and empowered work can increase inclusivity—that is, draw more closely on an individual's unique skills, perspectives, and talents because, by definition, those kinds of work are less managed and more guided. Open leadership clearly supports hiring for diversity exactly for the reason that it makes inclusivity so much richer. The ambiguity that's characteristic of the challenges we face in modern workplaces means that the work we do is ripe with potential for innovation—if we embrace risk and adapt our leadership styles to liberate it.
|
||||||
|
|
||||||
|
In other words:
|
||||||
|
|
||||||
|
> _Innovation = enabled (x) + empowered (x) / managed (x)_
|
||||||
|
>
|
||||||
|
> _The more enabled and empowered the work is, the more potential for innovation._
|
||||||
|
|
||||||
|
Focusing on the importance of enabled work and empowered work is not to devalue managed work in any way. I would say that managed work creates a stable foundation on which creative (enabled and empowered) work can blossom. Imagine if all the work we did was empowered; our organizations would be completely chaotic, undefined, and ambiguous. Organizations need a degree of managed work in order to ensure some direction, some understanding of priorities, and some definition of "quality."
|
||||||
|
|
||||||
|
Any role in any organization involves these three types of work occurring at various moments and in various situations. No job requires just one. As open leaders, we must recognize that work isn't an all-or-nothing, one-type-of-work-alone equation. We have to get better at understanding work in _these three different ways_ and using each one to the organization's advantage, depending on the situation.
|
||||||
|
|
||||||
|
--------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
via: https://opensource.com/open-organization/19/4/managed-enabled-empowered
|
||||||
|
|
||||||
|
作者:[Heidi Hess von Ludewig (Red Hat)][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/heidi-hess-von-ludewig/users/amatlack
|
||||||
|
[b]: https://github.com/lujun9972
|
||||||
|
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/BIZ_ControlNotDesirable.png?itok=nrXwSkv7
|
||||||
|
[2]: https://www.entrepreneur.com/article/288340
|
||||||
|
[3]: https://www.forbes.com/sites/lisaquast/2011/02/28/6-ways-to-empower-others-to-succeed/#5c860b365c62
|
||||||
|
[4]: https://opensource.com/open-organization/18/10/understanding-engagement-and-empowerment
|
||||||
|
[5]: https://opensource.com/open-organization/19/3/adaptive-leadership-review
|
@ -0,0 +1,57 @@
|
|||||||
|
[#]: collector: (lujun9972)
|
||||||
|
[#]: translator: ( )
|
||||||
|
[#]: reviewer: ( )
|
||||||
|
[#]: publisher: ( )
|
||||||
|
[#]: url: ( )
|
||||||
|
[#]: subject: (Testing Small Scale Scrum in the real world)
|
||||||
|
[#]: via: (https://opensource.com/article/19/4/next-steps-small-scale-scrum)
|
||||||
|
[#]: author: (Agnieszka Gancarczyk (Red Hat)Leigh Griffin (Red Hat) https://opensource.com/users/agagancarczyk/users/lgriffin/users/agagancarczyk/users/lgriffin)
|
||||||
|
|
||||||
|
Testing Small Scale Scrum in the real world
|
||||||
|
======
|
||||||
|
We plan to test the Small Scale Scrum framework in real-world projects
|
||||||
|
involving small teams.
|
||||||
|
![Green graph of measurements][1]
|
||||||
|
|
||||||
|
Scrum is built on the three pillars of inspection, adaptation, and transparency. Our empirical research is really the starting point in bringing scrum, one of the most popular agile implementations, to smaller teams. As presented in the diagram below, we are now taking time to inspect this framework and principles by testing them in real-world projects.
|
||||||
|
|
||||||
|
![small-scale-scrum-inspection.png][2]
|
||||||
|
|
||||||
|
Progress in empirical process control
|
||||||
|
|
||||||
|
We plan to implement Small Scale Scrum in several upcoming projects. Our test candidates are customers with real projects where teams of one to three people will undertake short-lived projects (ranging from a few weeks to three months) with an emphasis on quality and outputs. Individual projects, such as final-year projects (over 24 weeks) that are a capstone project after four years in a degree program, are almost exclusively completed by a single person. In projects of this nature, there is an emphasis on the project plan and structure and on maximizing the outputs that a single person can achieve.
|
||||||
|
|
||||||
|
We plan to metricize and publish the results of these projects and hold several retrospectives with the teams involved. We are particularly interested in metrics centered around quality, with a particular emphasis on quality in a software engineering context and management, both project management through the lifecycle with a customer and management of the day-to-day team activities and the delivery, release, handover, and signoff process.
|
||||||
|
|
||||||
|
Ultimately, we will retrospectively analyze the overall framework and principles and see if the Manifesto we envisioned holds up to the reality of executing a project with small numbers. From this data, we will produce the second version of Small Scale Scrum and begin a cyclic pattern of inspecting the model in new projects and adapting it again.
|
||||||
|
|
||||||
|
We want to do all of this transparently. This series of articles is one window into the data, the insights, the experiences, and the reality of running scrum for small teams whose everyday challenges include context switching, communication, and the need for a quality delivery. A follow-up series of articles is planned to examine the outputs and help develop the second edition of Small Scale Scrum entirely in the community.
|
||||||
|
|
||||||
|
We also plan to attend conferences and share our knowledge with the Agile community. Our first conference will be Agile 2019 where the evolution of Small Scale Scrum will be further explored as an Experience Report. We are advising colleges and sharing our structure and approach to managing and executing final-year projects. All our outputs will be freely available in the open source way.
|
||||||
|
|
||||||
|
Given the changes to recommended team sizes in the Scrum Guide, our long-term goal and vision is to have the Scrum Guide reflect that teams of one or more people occupying one or more roles within a project are capable of following scrum.
|
||||||
|
|
||||||
|
* * *
|
||||||
|
|
||||||
|
_Leigh Griffin will present Small Scale Scrum at Agile 2019 in Washington, August 5-9, 2019 as an Experience Report. An expanded paper will be published on[Agile Alliance][3] to accompany this._
|
||||||
|
|
||||||
|
* * *
|
||||||
|
|
||||||
|
* * *
|
||||||
|
|
||||||
|
--------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
via: https://opensource.com/article/19/4/next-steps-small-scale-scrum
|
||||||
|
|
||||||
|
作者:[Agnieszka Gancarczyk (Red Hat)Leigh Griffin (Red Hat)][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/agagancarczyk/users/lgriffin/users/agagancarczyk/users/lgriffin
|
||||||
|
[b]: https://github.com/lujun9972
|
||||||
|
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/metrics_lead-steps-measure.png?itok=DG7rFZPk (Green graph of measurements)
|
||||||
|
[2]: https://opensource.com/sites/default/files/small-scale-scrum-inspection.png (small-scale-scrum-inspection.png)
|
||||||
|
[3]: https://www.agilealliance.org/
|
@ -1,58 +1,61 @@
|
|||||||
关于 /dev/urandom 的流言终结
|
关于 /dev/urandom 的流言终结
|
||||||
======
|
======
|
||||||
|
|
||||||
有很多关于 /dev/urandom 和 /dev/random 的流言在坊间不断流传。流言终究是流言。
|
有很多关于 `/dev/urandom` 和 `/dev/random` 的流言在坊间不断流传。然而流言终究是流言。
|
||||||
本篇文章里针对的都是今年的 Linux 操作系统,其他类 Unix 操作系统不在讨论范围内。
|
|
||||||
|
|
||||||
### /dev/urandom 不安全。加密用途必须使用 /dev/random。
|
> 本篇文章里针对的都是近来的 Linux 操作系统,其它类 Unix 操作系统不在讨论范围内。
|
||||||
|
|
||||||
事实:/dev/urandom 才是类 Unix 操作系统下推荐的加密种子。
|
**`/dev/urandom` 不安全。加密用途必须使用 `/dev/random`**
|
||||||
|
|
||||||
### /dev/urandom 是伪随机数生成器(PRND),而 /dev/random 是“真”随机数生成器。
|
事实:`/dev/urandom` 才是类 Unix 操作系统下推荐的加密种子。
|
||||||
|
|
||||||
事实:他们两者本质上用的是同一种 CSPRNG (一种密码学伪随机数生成器)。他们之间细微的差别和“真”不“真”随机完全无关
|
**`/dev/urandom` 是<ruby>伪随机数生成器<rt>pseudo random number generator</rt></ruby>(PRND),而 `/dev/random` 是“真”随机数生成器。**
|
||||||
|
|
||||||
### /dev/random 在任何情况下都是密码学应用更好地选择。即便 /dev/urandom 也同样安全,我们还是不应该用 urandom。
|
事实:它们两者本质上用的是同一种 CSPRNG (一种密码学伪随机数生成器)。它们之间细微的差别和“真”不“真”随机完全无关
|
||||||
|
|
||||||
事实:/dev/random 有个很恶心人的问题:它是阻塞的。(译者:意味着请求都得逐个执行,等待前一个事件完成)
|
**`/dev/random` 在任何情况下都是密码学应用更好地选择。即便 `/dev/urandom` 也同样安全,我们还是不应该用它。**
|
||||||
|
|
||||||
### 但阻塞不是好事吗!/dev/random 只会给出电脑收集的信息熵足以支持的随机量。/dev/urandom 在用完了所有熵的情况下还会不断吐不安全的随机数给你。
|
事实:`/dev/random` 有个很恶心人的问题:它是阻塞的。(LCTT 译注:意味着请求都得逐个执行,等待前一个请求完成)
|
||||||
|
|
||||||
事实:这是误解。就算我们不去考虑应用层面后续对随机种子的用法,“用完信息熵池”这个概念本身就不存在。仅仅 256 bits 的熵就足以生成计算上安全的随机数很长,很长一段时间了。
|
**但阻塞不是好事吗!`/dev/random` 只会给出电脑收集的信息熵足以支持的随机量。`/dev/urandom` 在用完了所有熵的情况下还会不断吐不安全的随机数给你。**
|
||||||
|
|
||||||
问题的关键还在后头:/dev/random 怎么知道有系统会多少可用的信息熵?接着看!
|
事实:这是误解。就算我们不去考虑应用层面后续对随机种子的用法,“用完信息熵池”这个概念本身就不存在。仅仅 256 位的熵就足以生成计算上安全的随机数很长、很长的一段时间了。
|
||||||
|
|
||||||
### 但密码学家老是讨论重新选种子(re-seeding)。这难道不和上一条冲突吗?
|
问题的关键还在后头:`/dev/random` 怎么知道有系统会*多少*可用的信息熵?接着看!
|
||||||
|
|
||||||
|
**但密码学家老是讨论重新选种子(re-seeding)。这难道不和上一条冲突吗?**
|
||||||
|
|
||||||
事实:你说的也没错!某种程度上吧。确实,随机数生成器一直在使用系统信息熵的状态重新选种。但这么做(一部分)是因为别的原因。
|
事实:你说的也没错!某种程度上吧。确实,随机数生成器一直在使用系统信息熵的状态重新选种。但这么做(一部分)是因为别的原因。
|
||||||
|
|
||||||
这样说吧,我没有说引入新的信息熵是坏的。更多的熵肯定更好。我只是说在熵池低的时候阻塞是没必要的。
|
这样说吧,我没有说引入新的信息熵是坏的。更多的熵肯定更好。我只是说在熵池低的时候阻塞是没必要的。
|
||||||
|
|
||||||
### 好,就算你说的都对,但是 /dev/(u)random 的 man 页面和你说的也不一样啊!到底有没有专家同意你说的这堆啊?
|
**好,就算你说的都对,但是 `/dev/(u)random` 的 man 页面和你说的也不一样啊!到底有没有专家同意你说的这堆啊?**
|
||||||
|
|
||||||
事实:其实 man 页面和我说的不冲突。它看似好像在说 /dev/urandom 对密码学用途来说不安全,但如果你真的理解这堆密码学术语你就知道他说的并不是这个意思。
|
事实:其实 man 页面和我说的不冲突。它看似好像在说 `/dev/urandom` 对密码学用途来说不安全,但如果你真的理解这堆密码学术语你就知道它说的并不是这个意思。
|
||||||
|
|
||||||
man 页面确实说在一些情况下推荐使用 /dev/random (我觉得也没问题,但绝对不是说必要的),但它也推荐在大多数“一般”的密码学应用下使用 /dev/urandom 。
|
man 页面确实说在一些情况下推荐使用 `/dev/random` (我觉得也没问题,但绝对不是说必要的),但它也推荐在大多数“一般”的密码学应用下使用 `/dev/urandom` 。
|
||||||
|
|
||||||
虽然诉诸权威一般来说不是好事,但在密码学这么严肃的事情上,和专家统一意见是很有必要的。
|
虽然诉诸权威一般来说不是好事,但在密码学这么严肃的事情上,和专家统一意见是很有必要的。
|
||||||
|
|
||||||
所以说呢,还确实有一些专家和我的一件事一致的:/dev/urandom 就应该是类 UNIX 操作系统下密码学应用的首选。显然的,是他们的观点说服了我而不是反过来的。
|
所以说呢,还确实有一些*专家*和我的一件事一致的:`/dev/urandom` 就应该是类 UNIX 操作系统下密码学应用的首选。显然的,是他们的观点说服了我而不是反过来的。
|
||||||
|
|
||||||
|
------
|
||||||
|
|
||||||
难以相信吗?觉得我肯定错了?读下去看我能不能说服你。
|
难以相信吗?觉得我肯定错了?读下去看我能不能说服你。
|
||||||
|
|
||||||
我尝试不讲太高深的东西,但是有两点内容必须先提一下才能让我们接着论证观点。
|
我尝试不讲太高深的东西,但是有两点内容必须先提一下才能让我们接着论证观点。
|
||||||
|
|
||||||
首当其冲的,什么是随机性,或者更准确地:我们在探讨什么样的随机性?
|
首当其冲的,*什么是随机性*,或者更准确地:我们在探讨什么样的随机性?
|
||||||
|
|
||||||
另外一点很重要的是,我没有尝试以说教的态度对你们写这段话。我写这篇文章是为了日后可以在讨论起的时候指给别人看。比 140 字长(译者:推特长度)。这样我就不用一遍遍重复我的观点了。能把论点磨炼成一篇文章本身就很有助于将来的讨论。
|
另外一点很重要的是,我*没有尝试以说教的态度*对你们写这段话。我写这篇文章是为了日后可以在讨论起的时候指给别人看。比 140 字长(LCTT 译注:推特长度)。这样我就不用一遍遍重复我的观点了。能把论点磨炼成一篇文章本身就很有助于将来的讨论。
|
||||||
|
|
||||||
并且我非常乐意听到不一样的观点。但我只是认为单单地说 /dev/urandom 坏是不够的。你得能指出到底有什么问题,并且剖析他们。
|
并且我非常乐意听到不一样的观点。但我只是认为单单地说 `/dev/urandom` 坏是不够的。你得能指出到底有什么问题,并且剖析它们。
|
||||||
|
|
||||||
### 你是在说我笨?!
|
### 你是在说我笨?!
|
||||||
|
|
||||||
绝对没有!
|
绝对没有!
|
||||||
|
|
||||||
事实上我自己也相信了 “/dev/urandom 不安全的” 好些年。这几乎不是我们的错,因为那么德高望重的人在 Usenet,论坛,推特上根我们重复这个观点。甚至连 man page 都似是而非地说着。我们当年怎么可能打发诸如“信息熵太低了”这种看上去就很让人信服的观点呢?
|
事实上我自己也相信了 “`/dev/urandom` 是不安全的” 好些年。这几乎不是我们的错,因为那么德高望重的人在 Usenet、论坛、推特上跟我们重复这个观点。甚至*连 man 手册*都似是而非地说着。我们当年怎么可能鄙视诸如“信息熵太低了”这种看上去就很让人信服的观点呢?
|
||||||
|
|
||||||
整个流言之所以如此广为流传不是因为人们太蠢,而是因为但凡有点关于信息熵和密码学概念的人都会觉得这个说法很有道理。直觉似乎都在告诉我们这流言讲的很有道理。很不幸直觉在密码学里通常不管用,这次也一样。
|
整个流言之所以如此广为流传不是因为人们太蠢,而是因为但凡有点关于信息熵和密码学概念的人都会觉得这个说法很有道理。直觉似乎都在告诉我们这流言讲的很有道理。很不幸直觉在密码学里通常不管用,这次也一样。
|
||||||
|
|
||||||
@ -62,9 +65,9 @@ man 页面确实说在一些情况下推荐使用 /dev/random (我觉得也没
|
|||||||
|
|
||||||
我不想搞的太复杂以至于变成哲学范畴的东西。这种讨论很容易走偏因为随机模型大家见仁见智,讨论很快变得毫无意义。
|
我不想搞的太复杂以至于变成哲学范畴的东西。这种讨论很容易走偏因为随机模型大家见仁见智,讨论很快变得毫无意义。
|
||||||
|
|
||||||
在我看来真随机的“试金石”是量子效应。一个光子穿过或不穿过一个50%的半透镜。或者观察一个放射性粒子衰变。这类东西是现实世界最接近真随机的东西。当然,有些人也不相信这类过程是真随机的,或者这个世界根本不存在任何随机性。这个就百家争鸣我也不好多说什么了。
|
在我看来“真随机”的“试金石”是量子效应。一个光子穿过或不穿过一个半透镜。或者观察一个放射性粒子衰变。这类东西是现实世界最接近真随机的东西。当然,有些人也不相信这类过程是真随机的,或者这个世界根本不存在任何随机性。这个就百家争鸣了,我也不好多说什么了。
|
||||||
|
|
||||||
密码学家一般都会通过不去讨论什么是“真随机”来避免这种争论。他们更关心的是不可预测性。只要没有任何方法能猜出下一个随机数就可以了。所以当你以密码学应用为前提讨论一个随机数好不好的时候,在我看来这才是最重要的。
|
密码学家一般都会通过不去讨论什么是“真随机”来避免这种争论。它们更关心的是<ruby>不可预测性<rt> unpredictability</rt></ruby>。只要没有*任何*方法能猜出下一个随机数就可以了。所以当你以密码学应用为前提讨论一个随机数好不好的时候,在我看来这才是最重要的。
|
||||||
|
|
||||||
无论如何,我不怎么关心“哲学上安全”的随机数,这也包括别人嘴里的“真”随机数。
|
无论如何,我不怎么关心“哲学上安全”的随机数,这也包括别人嘴里的“真”随机数。
|
||||||
|
|
||||||
@ -72,25 +75,25 @@ man 页面确实说在一些情况下推荐使用 /dev/random (我觉得也没
|
|||||||
|
|
||||||
但就让我们退一步说,你有了一个“真”随机变量。你下一步做什么呢?
|
但就让我们退一步说,你有了一个“真”随机变量。你下一步做什么呢?
|
||||||
|
|
||||||
你把他们打印出来然后挂在墙上来战士量子宇宙的美与和谐?牛逼!我很理解你。
|
你把它们打印出来然后挂在墙上来展示量子宇宙的美与和谐?牛逼!我很理解你。
|
||||||
|
|
||||||
但是等等,你说你要用他们?做密码学用途?额,那这就废了,因为这事情就有点复杂了。
|
但是等等,你说你要*用*它们?做密码学用途?额,那这就废了,因为这事情就有点复杂了。
|
||||||
|
|
||||||
事情是这样的,你的真随机,量子力学加护的随机数即将被用进不理想的现实世界程序里。
|
事情是这样的,你的真随机,量子力学加护的随机数即将被用进不理想的现实世界程序里。
|
||||||
|
|
||||||
因为我们使用的大多数算法并不是 ### 理论信息学上安全的。**他们只能提供** 计算意义上的安全。我能想到为数不多的例外就只有 Shamir 密钥分享 和 One-time pad 算法。并且就算前者是名副其实的(如果你实际打算用的话),后者则毫无可行性可言。
|
因为我们使用的大多数算法并不是<ruby>理论信息学<rt>information-theoretic</rt></ruby>上安全的。它们“只能”提供 **计算意义上的安全**。我能想到为数不多的例外就只有 Shamir 密钥分享 和 One-time pad 算法。并且就算前者是名副其实的(如果你实际打算用的话),后者则毫无可行性可言。
|
||||||
|
|
||||||
但所有那些大名鼎鼎的密码学算法,AES,RSA,Diffie-Hellman, 椭圆曲线,还有所有那些加密软件包,OpenSSL,GnuTLS,Keyczar,你的操作系统的加密 API,都仅仅是计算意义上的安全的。
|
但所有那些大名鼎鼎的密码学算法,AES、RSA、Diffie-Hellman、椭圆曲线,还有所有那些加密软件包,OpenSSL、GnuTLS、Keyczar、你的操作系统的加密 API,都仅仅是计算意义上的安全的。
|
||||||
|
|
||||||
那区别是什么呢?理论信息学上的安全肯定是安全的,句号。其他那些的算法都可能在理论上被拥有无限计算力的穷举破解。我们依然愉快地使用他们因为全世界的计算机加起来都不可能在宇宙年龄的时间里破解,至少现在是这样。而这就是我们文章里说的“不安全”。
|
那区别是什么呢?理论信息学上的安全肯定是安全的,绝对是,其它那些的算法都可能在理论上被拥有无限计算力的穷举破解。我们依然愉快地使用它们因为全世界的计算机加起来都不可能在宇宙年龄的时间里破解,至少现在是这样。而这就是我们文章里说的“不安全”。
|
||||||
|
|
||||||
除非哪个聪明的家伙破解了算法本身——在只需要极少量计算力的情况下。这也是每个密码学家梦寐以求的圣杯:破解 AES 本身,破解 RSA 算法本身。
|
除非哪个聪明的家伙破解了算法本身——在只需要极少量计算力的情况下。这也是每个密码学家梦寐以求的圣杯:破解 AES 本身、破解 RSA 本身等等。
|
||||||
|
|
||||||
所以现在我们来到了更底层的东西:随机数生成器,你坚持要“真随机”而不是“伪随机”。但是没过一会儿你的真随机数就被喂进了你极为鄙视的伪随机算法里了!
|
所以现在我们来到了更底层的东西:随机数生成器,你坚持要“真随机”而不是“伪随机”。但是没过一会儿你的真随机数就被喂进了你极为鄙视的伪随机算法里了!
|
||||||
|
|
||||||
真相是,如果我们最先进的 hash 算法被破解了,或者最先进的块加密被破解了,你得到这些那些“哲学上不安全的”甚至无所谓了,因为反正你也没有安全的应用方法了。
|
真相是,如果我们最先进的 hash 算法被破解了,或者最先进的块加密被破解了,你得到这些那些“哲学上不安全的”甚至无所谓了,因为反正你也没有安全的应用方法了。
|
||||||
|
|
||||||
所以喂计算性上安全的随机数给你仅仅是计算性上安全的算法就可以了,换而言之,用 /dev/urandom。
|
所以把计算性上安全的随机数喂给你的仅仅是计算性上安全的算法就可以了,换而言之,用 `/dev/urandom`。
|
||||||
|
|
||||||
### Linux 随机数生成器的构架
|
### Linux 随机数生成器的构架
|
||||||
|
|
||||||
@ -100,19 +103,19 @@ man 页面确实说在一些情况下推荐使用 /dev/random (我觉得也没
|
|||||||
|
|
||||||
![image: mythical structure of the kernel's random number generator][1]
|
![image: mythical structure of the kernel's random number generator][1]
|
||||||
|
|
||||||
“真随机数”,尽管可能有点瑕疵,进入操作系统然后它的熵立刻被加入内部熵计数器。然后经过去 bias 和“漂白”之后它进入内核的熵池,然后 /dev/random 和 /dev/urandom 从里面生成随机数。
|
“真随机数”,尽管可能有点瑕疵,进入操作系统然后它的熵立刻被加入内部熵计数器。然后经过“矫偏”和“漂白”之后它进入内核的熵池,然后 `/dev/random` 和 `/dev/urandom` 从里面生成随机数。
|
||||||
|
|
||||||
“真”随机数生成器,/dev/random,直接从池里选出随机数,如果熵计数器表示能满足需要的数字大小,那就吐出数字并且减少熵计数。如果不够的话,他会阻塞程序直至有足够的熵进入和系统。
|
“真”随机数生成器,`/dev/random`,直接从池里选出随机数,如果熵计数器表示能满足需要的数字大小,那就吐出数字并且减少熵计数。如果不够的话,它会阻塞程序直至有足够的熵进入系统。
|
||||||
|
|
||||||
这里很重要一环是 /dev/random 几乎直接把那些进入系统的随机性吐了出来,不经扭曲。
|
这里很重要一环是 `/dev/random` 几乎只是仅经过必要的“漂白”后就直接把那些进入系统的随机性吐了出来,不经扭曲。
|
||||||
|
|
||||||
而对 /dev/urandom 来说,事情是一样的。除了当没有足够的熵的时候,它不会阻塞,而会从一直在运行的伪随机数生成器里吐出“底质量”的随机数。这个 CSPRNG 只会用“真随机数”生成种子一次(或者好几次,这不重要),但你不能特别相信它。
|
而对 `/dev/urandom` 来说,事情是一样的。除了当没有足够的熵的时候,它不会阻塞,而会从一直在运行的伪随机数生成器(当然,是密码学安全的,CSPRNG)里吐出“低质量”的随机数。这个 CSPRNG 只会用“真随机数”生成种子一次(或者好几次,这不重要),但你不能特别相信它。
|
||||||
|
|
||||||
在这种对随机数生成的理解下,很多人会觉得在 Linux 下尽量避免 /dev/urandom 看上去有那么点道理。
|
在这种对随机数生成的理解下,很多人会觉得在 Linux 下尽量避免 `/dev/urandom` 看上去有那么点道理。
|
||||||
|
|
||||||
因为要么你有足够多的熵,你会相当于用了 /dev/random。要么没有,那你就会从几乎没有高熵输入的 CSPRNG 那里得到一个低质量的随机数。
|
因为要么你有足够多的熵,你会相当于用了 `/dev/random`。要么没有,那你就会从几乎没有高熵输入的 CSPRNG 那里得到一个低质量的随机数。
|
||||||
|
|
||||||
看上去很邪恶是吧?很不幸的是这种看法是完全错误的。实际上,随机数生成器的构架更像是这样的。
|
看上去很邪恶是吧?很不幸的是这种看法是完全错误的。实际上,随机数生成器的构架更像是下面这样的。
|
||||||
|
|
||||||
#### 更好地简化
|
#### 更好地简化
|
||||||
|
|
||||||
@ -120,66 +123,65 @@ man 页面确实说在一些情况下推荐使用 /dev/random (我觉得也没
|
|||||||
|
|
||||||
![image: actual structure of the kernel's random number generator before Linux 4.8][2]
|
![image: actual structure of the kernel's random number generator before Linux 4.8][2]
|
||||||
|
|
||||||
这是个很粗糙的简化。实际上不仅有一个,而是三个熵池。一个主池,另一个给 /dev/random,还有一个给 /dev/urandom,后两者依靠从主池里获取熵。这三个池都有各自的熵计数器,但二级池(后两个)的计数器基本都在0附近,而“新鲜”的熵总在需要的时候从主池流过来。同时还有好多混合和回流进系统在同时进行。整个过程对于这篇文档来说都过于复杂了我们跳过。
|
> 这是个很粗糙的简化。实际上不仅有一个,而是三个熵池。一个主池,另一个给 `/dev/random`,还有一个给 `/dev/urandom`,后两者依靠从主池里获取熵。这三个池都有各自的熵计数器,但二级池(后两个)的计数器基本都在 0 附近,而“新鲜”的熵总在需要的时候从主池流过来。同时还有好多混合和回流进系统在同时进行。整个过程对于这篇文档来说都过于复杂了我们跳过。
|
||||||
|
|
||||||
但你看到最大的区别了吗? CSPRNG 并不是和随机数生成器一起跑用来填充 /dev/urandom 需要输出但熵不够的时候。CSPRNG 是整个随机数生成过程的内部组件之一。从来就没有什么 /dev/random 直接从池里输出纯纯的随机性。每个随机源的输入都在 CSPRNG 里充分混合和 hash 过了,这一切都发生在实际变成一个随机数,被/dev/urandom 或者 /dev/random 吐出去之前。
|
你看到最大的区别了吗?CSPRNG 并不是和随机数生成器一起跑的,以 `/dev/urandom` 需要输出但熵不够的时候进行填充。CSPRNG 是整个随机数生成过程的内部组件之一。从来就没有什么 `/dev/random` 直接从池里输出纯纯的随机性。每个随机源的输入都在 CSPRNG 里充分混合和散列过了,这一切都发生在实际变成一个随机数,被 `/dev/urandom` 或者 `/dev/random` 吐出去之前。
|
||||||
|
|
||||||
另外一个重要的区别是是这里没有熵计数器的任何事情,只有预估。一个源给你的熵的量并不是什么很明确能直接得到的数字。你得预估它。注意,如果你太乐观地预估了它,那 /dev/random 最重要的特性——只给出熵允许的随机量——就荡然无存了。很不幸的,预估熵的量是很困难的。
|
另外一个重要的区别是这里没有熵计数器的任何事情,只有预估。一个源给你的熵的量并不是什么很明确能直接得到的数字。你得预估它。注意,如果你太乐观地预估了它,那 `/dev/random` 最重要的特性——只给出熵允许的随机量——就荡然无存了。很不幸的,预估熵的量是很困难的。
|
||||||
|
|
||||||
Linux 内核只使用事件的到达时间来预估熵的量。它通过多项式插值,某种模型,来预估实际的到达时间有多“出乎意料”。这种多项式插值的方法到底是不是好的预估熵量的方法本身就是个问题。同时硬件情况会不会以某种特定的方式影响到达时间也是个问题。而所有硬件的取样率也是个问题,因为这基本上就直接决定了随机数到达时间的颗粒度。
|
Linux 内核只使用事件的到达时间来预估熵的量。它通过多项式插值,某种模型,来预估实际的到达时间有多“出乎意料”。这种多项式插值的方法到底是不是好的预估熵量的方法本身就是个问题。同时硬件情况会不会以某种特定的方式影响到达时间也是个问题。而所有硬件的取样率也是个问题,因为这基本上就直接决定了随机数到达时间的颗粒度。
|
||||||
|
|
||||||
说到最后,至少现在看来,内核的熵预估还是不错的。这也意味着它比较保守。有些人会具体地讨论它有多好,这都超出我的脑容量了。就算这样,如果你坚持不想在没有足够多的熵的情况下吐出随机数,那你看到这里可能还会有一丝紧张。我睡的就很香了,因为我不关心熵预估什么的。
|
说到最后,至少现在看来,内核的熵预估还是不错的。这也意味着它比较保守。有些人会具体地讨论它有多好,这都超出我的脑容量了。就算这样,如果你坚持不想在没有足够多的熵的情况下吐出随机数,那你看到这里可能还会有一丝紧张。我睡的就很香了,因为我不关心熵预估什么的。
|
||||||
|
|
||||||
最后强调一下终点:/dev/random 和 /dev/urandom 都是被同一个 CSPRNG 喂的输入。只有他们在用完各自熵池(根据某种预估标准)的时候,他们的行为会不同:/dev/random 阻塞,/dev/urandom 不阻塞。
|
最后强调一下终点:`/dev/random` 和 `/dev/urandom` 都是被同一个 CSPRNG 喂的输入。只有它们在用完各自熵池(根据某种预估标准)的时候,它们的行为会不同:`/dev/random` 阻塞,`/dev/urandom` 不阻塞。
|
||||||
|
|
||||||
##### Linux 4.8 以后
|
##### Linux 4.8 以后
|
||||||
|
|
||||||
在 Linux 4.8 里,/dev/random 和 /dev/urandom 的等价性被放弃了。现在 /dev/urandom 的输出不来自于熵池,而是直接从 CSPRNG 来。
|
在 Linux 4.8 里,`/dev/random` 和 `/dev/urandom` 的等价性被放弃了。现在 `/dev/urandom` 的输出不来自于熵池,而是直接从 CSPRNG 来。
|
||||||
|
|
||||||
![image: actual structure of the kernel's random number generator from Linux 4.8 onward][3]
|
![image: actual structure of the kernel's random number generator from Linux 4.8 onward][3]
|
||||||
|
|
||||||
我们很快会理解为什么这不是一个安全问题。
|
*我们很快会理解*为什么这不是一个安全问题。
|
||||||
|
|
||||||
### 阻塞有什么问题?
|
### 阻塞有什么问题?
|
||||||
|
|
||||||
你有没有需要等着 /dev/random 来吐随机数?比如在虚拟机里生成一个 PGP 密钥?或者访问一个在生成会话密钥的网站?
|
你有没有需要等着 `/dev/random` 来吐随机数?比如在虚拟机里生成一个 PGP 密钥?或者访问一个在生成会话密钥的网站?
|
||||||
|
|
||||||
这些都是问题。阻塞本质上会降低可用性。换而言之你的系统不干你让它干的事情。不用我说,这是不好的。要是它不 work 你干嘛搭建它呢?
|
这些都是问题。阻塞本质上会降低可用性。换而言之你的系统不干你让它干的事情。不用我说,这是不好的。要是它不干活你干嘛搭建它呢?
|
||||||
|
|
||||||
我在工厂自动化里做过和安全相关的系统。猜猜看安全系统失效的主要原因是什么?被错误操作。就这么简单。很多安全措施的流程让工人恼火了。比如时间太长,或者太不方便。你要知道人很会找捷径来“解决”问题。
|
> 我在工厂自动化里做过和安全相关的系统。猜猜看安全系统失效的主要原因是什么?被错误操作。就这么简单。很多安全措施的流程让工人恼火了。比如时间太长,或者太不方便。你要知道人很会找捷径来“解决”问题。
|
||||||
|
|
||||||
但其实有个更深刻的问题:人们不喜欢被打断。他们会找一些绕过的方法,把一些诡异的东西接在一起仅仅因为这样能用。一般人根本不知道什么密码学什么乱七八糟的,至少正常的人是这样吧。
|
但其实有个更深刻的问题:人们不喜欢被打断。它们会找一些绕过的方法,把一些诡异的东西接在一起仅仅因为这样能用。一般人根本不知道什么密码学什么乱七八糟的,至少正常的人是这样吧。
|
||||||
|
|
||||||
为什么不禁止调用 `random()`?为什么不随便在论坛上找个人告诉你用写奇异的 ioctl 来增加熵计数器呢?为什么不干脆就把 SSL 加密给关了算了呢?
|
为什么不禁止调用 `random()`?为什么不随便在论坛上找个人告诉你用写奇异的 ioctl 来增加熵计数器呢?为什么不干脆就把 SSL 加密给关了算了呢?
|
||||||
|
|
||||||
到头来如果东西太难用的话,你的用户就会被迫开始做一些降低系统安全性的事情——你甚至不知道他们会做些什么。
|
到头来如果东西太难用的话,你的用户就会被迫开始做一些降低系统安全性的事情——你甚至不知道它们会做些什么。
|
||||||
|
|
||||||
我们很容易会忽视可用性之类的重要性。毕竟安全第一对吧?所以比起牺牲安全,不可用,难用,不方便都是次要的?
|
我们很容易会忽视可用性之类的重要性。毕竟安全第一对吧?所以比起牺牲安全,不可用,难用,不方便都是次要的?
|
||||||
|
|
||||||
这种二元对立的想法是错的。阻塞不一定就安全了。正如我们看到的,/dev/urandom 直接从 CSPRNG 里给你一样好的随机数。用它不好吗!
|
这种二元对立的想法是错的。阻塞不一定就安全了。正如我们看到的,`/dev/urandom` 直接从 CSPRNG 里给你一样好的随机数。用它不好吗!
|
||||||
|
|
||||||
### CSPRNG 没问题
|
### CSPRNG 没问题
|
||||||
|
|
||||||
现在情况听上去很沧桑。如果连高质量的 /dev/random 都是从一个 CSPRNG 里来的,我们怎么敢在高安全性的需求上使用它呢?
|
现在情况听上去很沧桑。如果连高质量的 `/dev/random` 都是从一个 CSPRNG 里来的,我们怎么敢在高安全性的需求上使用它呢?
|
||||||
|
|
||||||
实际上,“看上去随机”是现存大多数密码学算法的更集。如果你观察一个密码学 hash 的输出,它得和随机的字符串不可区分,密码学家才会认可这个算法。如果你生成一个块加密,它的输出(在你不知道密钥的情况下)也必须和随机数据不可区分才行。
|
实际上,“看上去随机”是现存大多数密码学基础组件的基本要求。如果你观察一个密码学哈希的输出,它一定得和随机的字符串不可区分,密码学家才会认可这个算法。如果你生成一个块加密,它的输出(在你不知道密钥的情况下)也必须和随机数据不可区分才行。
|
||||||
|
|
||||||
如果任何人能比暴力穷举要更有效地破解一个加密,比如它利用了某些 CSPRNG 伪随机的弱点,那这就又是老一套了:一切都废了,也别谈后面的了。块加密,hash,一切都是基于某个数学算法,比如 CSPRNG。所以别害怕,到头来都一样。
|
如果任何人能比暴力穷举要更有效地破解一个加密,比如它利用了某些 CSPRNG 伪随机的弱点,那这就又是老一套了:一切都废了,也别谈后面的了。块加密、哈希,一切都是基于某个数学算法,比如 CSPRNG。所以别害怕,到头来都一样。
|
||||||
|
|
||||||
### 那熵池快空了的情况呢?
|
### 那熵池快空了的情况呢?
|
||||||
|
|
||||||
毫无影响。
|
毫无影响。
|
||||||
|
|
||||||
加密算法的根基建立在攻击者不能预测输出上,只要最一开始有足够的随机性(熵)就行了。一般的下限是 256 bits,不需要更多了。
|
加密算法的根基建立在攻击者不能预测输出上,只要最一开始有足够的随机性(熵)就行了。一般的下限是 256 位,不需要更多了。
|
||||||
|
|
||||||
介于我们一直在很随意的使用“熵”这个概念,我用 bits 来量化随机性希望读者不要太在意细节。像我们之前讨论的那样,内核的随机数生成器甚至没法精确地知道进入系统的熵的量。只有一个预估。而且这个预估的准确性到底怎么样也没人知道。
|
介于我们一直在很随意的使用“熵”这个概念,我用“位”来量化随机性希望读者不要太在意细节。像我们之前讨论的那样,内核的随机数生成器甚至没法精确地知道进入系统的熵的量。只有一个预估。而且这个预估的准确性到底怎么样也没人知道。
|
||||||
It doesn't matter.
|
|
||||||
|
|
||||||
### 重新选种
|
### 重新选种
|
||||||
|
|
||||||
但如果熵这么不重要,为什么还要有新的熵一直被收进随机数生成器里呢?
|
但如果熵这么不重要,为什么还要有新的熵一直被收进随机数生成器里呢?
|
||||||
|
|
||||||
djb [提到][4] 太多的熵甚至可能会起到反效果。
|
> djb [提到][4] 太多的熵甚至可能会起到反效果。
|
||||||
|
|
||||||
首先,一般不会这样。如果你有很多随机性可以拿来用,用就对了!
|
首先,一般不会这样。如果你有很多随机性可以拿来用,用就对了!
|
||||||
|
|
||||||
@ -189,92 +191,90 @@ djb [提到][4] 太多的熵甚至可能会起到反效果。
|
|||||||
|
|
||||||
你已经凉了,因为攻击者可以计算出所有未来会被输出的随机数了。
|
你已经凉了,因为攻击者可以计算出所有未来会被输出的随机数了。
|
||||||
|
|
||||||
但是,如果不断有新的熵被混进系统,那内部状态会在一次变得随机起来。所以随机数生成器被设计成这样有些“自愈”能力。
|
但是,如果不断有新的熵被混进系统,那内部状态会再一次变得随机起来。所以随机数生成器被设计成这样有些“自愈”能力。
|
||||||
|
|
||||||
但这是在给内部状态引入新的熵,这和阻塞输出没有任何关系。
|
但这是在给内部状态引入新的熵,这和阻塞输出没有任何关系。
|
||||||
|
|
||||||
|
|
||||||
### random 和 urandom 的 man 页面
|
### random 和 urandom 的 man 页面
|
||||||
|
|
||||||
这两个 man 页面在吓唬程序员方面很有建树:
|
这两个 man 页面在吓唬程序员方面很有建树:
|
||||||
|
|
||||||
> 从 /dev/urandom 读取数据不会因为需要更多熵而阻塞。这样的结果是,如果熵池里没有足够多的熵,取决于驱动使用的算法,返回的数值在理论上有被密码学攻击的可能性。发动这样攻击的步骤并没有出现在任何公开文献当中,但这样的攻击从理论上讲是可能存在的。如果你的应用担心这类情况,你应该使用 /dev/random。
|
> 从 `/dev/urandom` 读取数据不会因为需要更多熵而阻塞。这样的结果是,如果熵池里没有足够多的熵,取决于驱动使用的算法,返回的数值在理论上有被密码学攻击的可能性。发动这样攻击的步骤并没有出现在任何公开文献当中,但这样的攻击从理论上讲是可能存在的。如果你的应用担心这类情况,你应该使用 `/dev/random`。
|
||||||
|
|
||||||
没有“公开的文献”描述,但是 NSA 的小卖部里肯定卖这种攻击手段是吧?如果你真的真的很担心(你应该很担心),那就用 /dev/random 然后所有问题都没了?
|
>> 实际上已经有 `/dev/random` 和 `/dev/urandom` 的 Linux 内核 man 页面的更新版本。不幸的是,随便一个网络搜索出现我在结果顶部的仍然是旧的、有缺陷的版本。此外,许多 Linux 发行版仍在发布旧的 man 页面。所以不幸的是,这一节需要在这篇文章中保留更长的时间。我很期待删除这一节!
|
||||||
|
|
||||||
然而事实是,可能什么情报局有这种攻击,或者什么邪恶黑客组织找到了方法。但如果我们就直接假设这种攻击一定存在也是不合理的。
|
没有“公开的文献”描述,但是 NSA 的小卖部里肯定卖这种攻击手段是吧?如果你真的真的很担心(你应该很担心),那就用 `/dev/random` 然后所有问题都没了?
|
||||||
|
|
||||||
而且就算你想给自己一个安心,我要给你泼个冷水:AES,SHA-3 或者其他什么常见的加密算法也没有“公开文献记述”的攻击手段。难道你也不用这几个加密算法了?这显然是可笑的。
|
然而事实是,可能某个什么情报局有这种攻击,或者某个什么邪恶黑客组织找到了方法。但如果我们就直接假设这种攻击一定存在也是不合理的。
|
||||||
|
|
||||||
我们在回到 man 页面说:“使用 /dev/random”。我们已经知道了,虽然 /dev/urandom 不阻塞,但是它的随机数和 /dev/random 都是从同一个 CSPRNG 里来的。
|
而且就算你想给自己一个安心,我要给你泼个冷水:AES、SHA-3 或者其它什么常见的加密算法也没有“公开文献记述”的攻击手段。难道你也不用这几个加密算法了?这显然是可笑的。
|
||||||
|
|
||||||
如果你真的需要信息论理论上安全的随机数(你不需要的相信我),那才有可能成为唯一一个你需要等足够熵进入 CSPRNG 的理由。而且你也不能用 /dev/random。
|
我们在回到 man 页面说:“使用 `/dev/random`”。我们已经知道了,虽然 `/dev/urandom` 不阻塞,但是它的随机数和 `/dev/random` 都是从同一个 CSPRNG 里来的。
|
||||||
|
|
||||||
|
如果你真的需要信息论理论上安全的随机数(你不需要的,相信我),那才有可能成为唯一一个你需要等足够熵进入 CSPRNG 的理由。而且你也不能用 `/dev/random`。
|
||||||
|
|
||||||
man 页面有毒,就这样。但至少它还稍稍挽回了一下自己:
|
man 页面有毒,就这样。但至少它还稍稍挽回了一下自己:
|
||||||
> 如果你不确定该用 /dev/random 还是 /dev/urandom ,那你可能应该用后者。通常来说,除了需要长期使用的 GPG/SSL/SSH 密钥以外,你总该使用/dev/urandom 。
|
|
||||||
|
|
||||||
行。我觉得没必要,但如果你真的要用 /dev/random 来生成 “长期使用的密钥”,用就是了也没人拦着!你可能需要等几秒钟或者敲几下键盘来增加熵,但没什么问题。
|
> 如果你不确定该用 `/dev/random` 还是 `/dev/urandom` ,那你可能应该用后者。通常来说,除了需要长期使用的 GPG/SSL/SSH 密钥以外,你总该使用`/dev/urandom` 。
|
||||||
|
|
||||||
|
>> 该手册页的[当前更新版本](http://man7.org/linux/man-pages/man4/random.4.html)毫不含糊地说:
|
||||||
|
|
||||||
|
>> `/dev/random` 接口被认为是遗留接口,并且 `/dev/urandom` 在所有用例中都是首选和足够的,除了在启动早期需要随机性的应用程序;对于这些应用程序,必须替代使用 `getrandom(2)`,因为它将阻塞,直到熵池初始化完成。
|
||||||
|
|
||||||
|
行。我觉得没必要,但如果你真的要用 `/dev/random` 来生成 “长期使用的密钥”,用就是了也没人拦着!你可能需要等几秒钟或者敲几下键盘来增加熵,但这没什么问题。
|
||||||
|
|
||||||
但求求你们,不要就因为“你想更安全点”就让连个邮件服务器要挂起半天。
|
但求求你们,不要就因为“你想更安全点”就让连个邮件服务器要挂起半天。
|
||||||
|
|
||||||
### 正道
|
### 正道
|
||||||
|
|
||||||
本篇文章里的观点显然在互联网上是“小众”的。但如果问问一个真正的密码学家,你很难找到一个认同阻塞 /dev/random 的人。
|
本篇文章里的观点显然在互联网上是“小众”的。但如果问问一个真正的密码学家,你很难找到一个认同阻塞 `/dev/random` 的人。
|
||||||
|
|
||||||
比如我们看看 [Daniel Bernstein][5] djb:
|
比如我们看看 [Daniel Bernstein][5](即著名的 djb)的看法:
|
||||||
|
|
||||||
> 我们密码学家对这种胡乱迷信行为表示不负责。你想想,写 /dev/random man 页面的人好像同时相信:
|
> 我们密码学家对这种胡乱迷信行为表示不负责。你想想,写 `/dev/random` man 页面的人好像同时相信:
|
||||||
>
|
>
|
||||||
> * (1) 我们不知道如何用一个 256-bit 长的 /dev/random 的输出来生成一个无限长的随机密钥串流(这是我们需要 /dev/urandom 吐出来的),但与此同时
|
> * (1) 我们不知道如何用一个 256 位长的 `/dev/random` 的输出来生成一个无限长的随机密钥串流(这是我们需要 `/dev/urandom` 吐出来的),但与此同时
|
||||||
> * (2) 我们却知道怎么用单个密钥来加密一条消息(这是 SSL,PGP 之类干的事情)
|
> * (2) 我们却知道怎么用单个密钥来加密一条消息(这是 SSL,PGP 之类干的事情)
|
||||||
>
|
|
||||||
>
|
|
||||||
|
|
||||||
>
|
>
|
||||||
> 对密码学家来说这甚至都不好笑了
|
> 对密码学家来说这甚至都不好笑了
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
或早 [Thomas Pornin][6],他也是我在 stackexchange 上见过最乐于助人的一位:
|
或者 [Thomas Pornin][6] 的看法,他也是我在 stackexchange 上见过最乐于助人的一位:
|
||||||
|
|
||||||
> 简单来说,是的。展开说,答案还是一样。/dev/urandom 生成的数据可以说和真随机完全无法区分,至少在现有科技水平下。使用比 /dev/urandom “更好的“随机性毫无意义,除非你在使用极为罕见的“信息论安全”的加密算法。这肯定不是你的情况,不然你早就说了。
|
> 简单来说,是的。展开说,答案还是一样。`/dev/urandom` 生成的数据可以说和真随机完全无法区分,至少在现有科技水平下。使用比 `/dev/urandom` “更好的“随机性毫无意义,除非你在使用极为罕见的“信息论安全”的加密算法。这肯定不是你的情况,不然你早就说了。
|
||||||
>
|
>
|
||||||
> urandom 的 man 页面多多少少有些误导人,或者干脆可以说是错的——特别是当它说 /dev/urandom 会“用完熵”以及 “/dev/random 是更好的”那几句话;
|
> urandom 的 man 页面多多少少有些误导人,或者干脆可以说是错的——特别是当它说 `/dev/urandom` 会“用完熵”以及 “`/dev/random` 是更好的”那几句话;
|
||||||
|
|
||||||
|
或者 [Thomas Ptacek][7] 的看法,他不设计密码算法或者密码学系统,但他是一家名声在外的安全咨询公司的创始人,这家公司负责很多渗透和破解烂密码学算法的测试:
|
||||||
|
|
||||||
或者 [Thomas Ptacek][7],他不设计密码算法或者密码学系统,但他是一家名声在外的安全咨询公司的创始人,这家公司负责很多渗透和破解烂密码学算法的测试:
|
|
||||||
|
|
||||||
> 用 urandom。用 urandom。用 urandom。用 urandom。用 urandom。
|
> 用 urandom。用 urandom。用 urandom。用 urandom。用 urandom。
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
### 没有完美
|
### 没有完美
|
||||||
|
|
||||||
/dev/urandom 不是完美的,问题分两层:
|
`/dev/urandom` 不是完美的,问题分两层:
|
||||||
|
|
||||||
在 Linux 上,不像 FreeBSD,/dev/urandom 永远不阻塞。记得安全性取决于某个最一开始决定的随机性?种子?
|
在 Linux 上,不像 FreeBSD,`/dev/urandom` 永远不阻塞。记得安全性取决于某个最一开始决定的随机性?种子?
|
||||||
|
|
||||||
Linux 的 /dev/urandom 会很乐意给你吐点不怎么随机的随机数,甚至在内核有机会收集一丁点熵之前。什么时候有这种情况?当你系统刚刚启动的时候。
|
Linux 的 `/dev/urandom` 会很乐意给你吐点不怎么随机的随机数,甚至在内核有机会收集一丁点熵之前。什么时候有这种情况?当你系统刚刚启动的时候。
|
||||||
|
|
||||||
FreeBSD 的行为更正确点:/dev/random 和 /dev/urandom 是一样的,在系统启动的时候 /dev/random 会阻塞到有足够的熵为止,然后他们都再也不阻塞了。
|
FreeBSD 的行为更正确点:`/dev/random` 和 `/dev/urandom` 是一样的,在系统启动的时候 `/dev/random` 会阻塞到有足够的熵为止,然后它们都再也不阻塞了。
|
||||||
|
|
||||||
与此同时 Linux 实行了一个新的 syscall,最早由 OpenBSD 引入叫 getentrypy(2),在 Linux 下这个叫 getrandom(2)。这个 syscall 有着上述正确的行为:阻塞到有足够的熵为止,然后再也不阻塞了。当然,这是个 syscall,而不是一个字节设备(译者:指不在 /dev/ 下),所以它在 shell 或者别的脚本语言里没那么容易获取。这个 syscall 自 Linux 3.17 起存在。
|
> 与此同时 Linux 实行了一个新的<ruby>系统调用<rt>syscall</rt></ruby>,最早由 OpenBSD 引入叫 `getentrypy(2)`,在 Linux 下这个叫 `getrandom(2)`。这个系统调用有着上述正确的行为:阻塞到有足够的熵为止,然后再也不阻塞了。当然,这是个系统调用,而不是一个字节设备(LCTT 译注:指不在 `/dev/` 下),所以它在 shell 或者别的脚本语言里没那么容易获取。这个系统调用 自 Linux 3.17 起存在。
|
||||||
|
|
||||||
在 Linux 上其实这个问题不太大,因为 Linux 发行版会在启动的过程中储蓄一点随机数(这发生在已经有一些熵之后,因为启动程序不会在按下电源的一瞬间就开始运行)到一个种子文件,以便系统下次启动的时候读取。所以每次启动的时候系统都会从上一次会话里带一点随机性过来。
|
在 Linux 上其实这个问题不太大,因为 Linux 发行版会在启动的过程中储蓄一点随机数(这发生在已经有一些熵之后,因为启动程序不会在按下电源的一瞬间就开始运行)到一个种子文件中,以便系统下次启动的时候读取。所以每次启动的时候系统都会从上一次会话里带一点随机性过来。
|
||||||
|
|
||||||
显然这比不上在关机脚本里写入一些随机种子,因为这样的显然就有更多熵可以操作了。但这样做显而易见的好处就是它不关心系统是不是正确关机了,比如可能你系统崩溃了。
|
显然这比不上在关机脚本里写入一些随机种子,因为这样的显然就有更多熵可以操作了。但这样做显而易见的好处就是它不用关心系统是不是正确关机了,比如可能你系统崩溃了。
|
||||||
|
|
||||||
而且这种做法在你真正第一次启动系统的时候也没法帮你随机,不过好在系统安装器一般会写一个种子文件,所以基本上问题不大。
|
而且这种做法在你真正第一次启动系统的时候也没法帮你随机,不过好在系统安装器一般会写一个种子文件,所以基本上问题不大。
|
||||||
|
|
||||||
虚拟机是另外一层问题。因为用户喜欢克隆他们,或者恢复到某个之前的状态。这种情况下那个种子文件就帮不到你了。
|
虚拟机是另外一层问题。因为用户喜欢克隆它们,或者恢复到某个之前的状态。这种情况下那个种子文件就帮不到你了。
|
||||||
|
|
||||||
但解决方案依然和用 /dev/random 没关系,而是你应该正确的给每个克隆或者恢复的的镜像重新生成种子文件,之类的。
|
但解决方案依然和用 `/dev/random` 没关系,而是你应该正确的给每个克隆或者恢复的镜像重新生成种子文件。
|
||||||
|
|
||||||
### 太长不看;
|
### 太长不看
|
||||||
|
|
||||||
别问,问就是用 /dev/urandom !
|
|
||||||
|
|
||||||
|
别问,问就是用 `/dev/urandom` !
|
||||||
|
|
||||||
--------------------------------------------------------------------------------
|
--------------------------------------------------------------------------------
|
||||||
|
|
||||||
@ -282,14 +282,14 @@ via: https://www.2uo.de/myths-about-urandom/
|
|||||||
|
|
||||||
作者:[Thomas Hühn][a]
|
作者:[Thomas Hühn][a]
|
||||||
译者:[Moelf](https://github.com/Moelf)
|
译者:[Moelf](https://github.com/Moelf)
|
||||||
校对:[校对者ID](https://github.com/校对者ID)
|
校对:[wxy](https://github.com/wxy)
|
||||||
|
|
||||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
|
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
|
||||||
|
|
||||||
[a]:https://www.2uo.de/
|
[a]:https://www.2uo.de/
|
||||||
[1]:https://www.2uo.de/myths-about-urandom/structure-no.png
|
[1]:https://www.2uo.de/_media/wiki:structure-no.png
|
||||||
[2]:https://www.2uo.de/myths-about-urandom/structure-yes.png
|
[2]:https://www.2uo.de/_media/wiki:structure-yes.png
|
||||||
[3]:https://www.2uo.de/myths-about-urandom/structure-new.png
|
[3]:https://www.2uo.de/_media/wiki:structure-new.png
|
||||||
[4]:http://blog.cr.yp.to/20140205-entropy.html
|
[4]:http://blog.cr.yp.to/20140205-entropy.html
|
||||||
[5]:http://www.mail-archive.com/cryptography@randombit.net/msg04763.html
|
[5]:http://www.mail-archive.com/cryptography@randombit.net/msg04763.html
|
||||||
[6]:http://security.stackexchange.com/questions/3936/is-a-rand-from-dev-urandom-secure-for-a-login-key/3939#3939
|
[6]:http://security.stackexchange.com/questions/3936/is-a-rand-from-dev-urandom-secure-for-a-login-key/3939#3939
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
[#]: collector: (lujun9972)
|
[#]: collector: (lujun9972)
|
||||||
[#]: translator: ( )
|
[#]: translator: (MjSeven)
|
||||||
[#]: reviewer: ( )
|
[#]: reviewer: ( )
|
||||||
[#]: publisher: ( )
|
[#]: publisher: ( )
|
||||||
[#]: url: ( )
|
[#]: url: ( )
|
||||||
@ -7,69 +7,68 @@
|
|||||||
[#]: via: (https://www.2daygeek.com/how-to-install-and-enable-flatpak-support-on-linux/)
|
[#]: via: (https://www.2daygeek.com/how-to-install-and-enable-flatpak-support-on-linux/)
|
||||||
[#]: author: (Magesh Maruthamuthu https://www.2daygeek.com/author/magesh/)
|
[#]: author: (Magesh Maruthamuthu https://www.2daygeek.com/author/magesh/)
|
||||||
|
|
||||||
How To Install And Enable Flatpak Support On Linux?
|
如何在 Linux 上安装并启用 Flatpak 支持?
|
||||||
======
|
======
|
||||||
|
|
||||||
Currently we all are using distributions official package managers to install any required packages.
|
<to 校正:之前似乎发表过跟这个类似的一篇 https://linux.cn/article-10459-1.html>
|
||||||
|
|
||||||
in Linux, it’s doing good without any issues. (It’s doing their job nicely without any compromise)
|
目前,我们都在使用 Linux 发行版的官方软件包管理器来安装所需的软件包。
|
||||||
|
|
||||||
There was some limitation on this that will think about other alternative solutions to fix it.
|
在 Linux 中,它做得很好,没有任何问题。(它很好地完成了它应该做的工作,同时它没有任何妥协)
|
||||||
|
|
||||||
Yes, by default we won’t get the latest version of packages from the distributions official package managers because as these were built while building a current OS version. And they offers only security updates until the next major release comes.
|
在一些方面它也有一些限制,所以会让我们考虑其他替代解决方案来解决。
|
||||||
|
|
||||||
So, what will be the solution for this?
|
是的,默认情况下,我们不会从发行版官方软件包管理器获取最新版本的软件包,因为这些软件包是在构建当前 OS 版本时构建的。它们只会提供安全更新,直到下一个主要版本发布。
|
||||||
|
|
||||||
Yes, we have multiple solutions for this and most of us were already started using few of those.
|
那么,这种情况有什么解决办法吗?
|
||||||
|
|
||||||
What it is and what is the benefit of those?
|
是的,我们有多种解决方案,而且我们大多数人已经开始使用其中的一些了。
|
||||||
|
|
||||||
* **For Ubuntu based systems:** PPAs
|
有些什么呢,它们有什么好处?
|
||||||
* **For RHEL based systems:** [EPEL Repository][1], [ELRepo Repository][2], [nux-dextop Repository][3], [IUS Community Repo][4], [RPMfusion Repository][5] and [Remi Repository][6].
|
|
||||||
|
* **对于基于 Ubuntu 的系统:** PPAs
|
||||||
|
* **对于基于 RHEL 的系统:** [EPEL Repository][1]、[ELRepo Repository][2]、[nux-dextop Repository][3]、[IUS Community Repo][4]、[RPMfusion Repository][5] 和 [Remi Repository][6]
|
||||||
|
|
||||||
|
|
||||||
|
使用上面的仓库,我们将获得最新的软件包。这些软件包通常都得到了很好的维护,还有大多数社区的建议。但这对于操作系统来说应该是适当的,因为它们可能并不安全。
|
||||||
|
|
||||||
Using the above repos, we will be getting the latest packages for the distribution. And these are usually well maintained and suggested by most of the community. But these are advisable by the OS and may not always be safe.
|
近年来,出现了一下通用软件包封装格式,并且得到了广泛的应用。
|
||||||
|
|
||||||
In recent years, the following universal packaging formats were come out and gained a lot of popularity.
|
* **`Flatpak:`** 它是独立于发行版的包格式,主要贡献者是 Fedora 项目团队。大多数主要的 Linux 发行版都采用了 Flatpak 框架。
|
||||||
|
* **`Snaps:`** Snappy 是一种通用的软件包封装格式,最初由 Canonical 为 Ubuntu 手机及其操作系统设计和构建的。后来,大多数发行版都进行了改编。
|
||||||
|
* **`AppImage:`** AppImage 是一种可移植的包格式,可以在不安装或不需要 root 权限的情况下运行。
|
||||||
|
|
||||||
* **`Flatpak:`**`` It’s distribution independent package format and the main contributor is Fedora project team. The Flatpak framework is adopted by most of the major Linux distributions.
|
我们之前已经介绍过 **[Snap 包管理器和包封装格式][7]**。今天我们将讨论 Flatpak 包封装格式。
|
||||||
* **`Snaps:`**`` Snappy is a universal packaging formats originally designed and built by Canonical for the Ubuntu phone and it’s operating system. Later most of the distributions are adapted.
|
|
||||||
* **`AppImage:`**`` AppImage is a portable package format and it can run without installation or the need for root rights.
|
|
||||||
|
|
||||||
|
### 什么是 Flatpak?
|
||||||
|
|
||||||
|
Flatpak(以前称为 X Desktop Group 或 xdg-app)是一个软件实用程序。它提供了一种通用的包封装格式,可以在任何 Linux 发行版中使用。
|
||||||
|
|
||||||
We had already covered about the **[Snap package manager& packaging format][7]** in the past. Today we are going to discuss about Flatpak packing format.
|
它提供了一个沙箱(隔离的)环境来运行应用程序,不会影响其他应用程序和发行版核心软件包。我们还可以安装并运行不同版本的软件包。
|
||||||
|
|
||||||
### What Is Flatpak?
|
Flatpak 的一个缺点是不像 Snap 和 AppImage 那样支持服务器操作系统,它只在少数桌面环境下工作。
|
||||||
|
|
||||||
Flatpak (formerly know as X Desktop Group or xdg-app) is a software utility. It’s offering a universal packaging formats which can be used in any Linux distributions.
|
比如说,如果你想在系统上运行两个版本的 php,那么你可以轻松安装并按照你的意愿运行。
|
||||||
|
|
||||||
It provides a sandbox (isolated) environment to run the app and it doesn’t impact either other apps and distribution core packages. Also we can install and run the different version of same package.
|
这就是现在通用包封装格式非常有名的地方。
|
||||||
|
|
||||||
There is an disadvantage on flatpak is that doesn’t support server OS unlike Snap and AppImage. It’s working only on few desktops environment.
|
### 如何在 Linux 中安装 Flatpak?
|
||||||
|
|
||||||
Say for example. If you would like to run two version of php on your system then you can easily install and run as your wish.
|
大多数 Linux 发行版官方仓库都提供 Flatpak 软件包。因此,可以使用它们来进行安装。
|
||||||
|
|
||||||
That’s where the universal packaging formats are become very famous nowadays.
|
对于 **`Fedora`** 系统,使用 **[DNF 命令][8]** 来安装 flatpak。
|
||||||
|
|
||||||
### How To Install Flatpak On Linux?
|
|
||||||
|
|
||||||
Flatpak package is available in most of the Linux distribution official repository. Hence, it can be installed using those.
|
|
||||||
|
|
||||||
For **`Fedora`** system, use **[DNF Command][8]** to install flatpak.
|
|
||||||
|
|
||||||
```
|
```
|
||||||
$ sudo dnf install flatpak
|
$ sudo dnf install flatpak
|
||||||
```
|
```
|
||||||
|
|
||||||
For **`Debian/Ubuntu`** systems, use **[APT-GET Command][9]** or **[APT Command][10]** to install flatpak.
|
对于 **`Debian/Ubuntu`** 系统,使用 **[APT-GET 命令][9]** 或 **[APT 命令][10]** 来安装 flatpak。
|
||||||
|
|
||||||
```
|
```
|
||||||
$ sudo apt install flatpak
|
$ sudo apt install flatpak
|
||||||
```
|
```
|
||||||
|
|
||||||
For older Ubuntu versions.
|
对于较旧的 Ubuntu 版本:
|
||||||
|
|
||||||
```
|
```
|
||||||
$ sudo add-apt-repository ppa:alexlarsson/flatpak
|
$ sudo add-apt-repository ppa:alexlarsson/flatpak
|
||||||
@ -77,52 +76,52 @@ $ sudo apt update
|
|||||||
$ sudo apt install flatpak
|
$ sudo apt install flatpak
|
||||||
```
|
```
|
||||||
|
|
||||||
For **`Arch Linux`** based systems, use **[Pacman Command][11]** to install flatpak.
|
对于基于 **`Arch Linux`** 的系统,使用 **[Pacman 命令][11]** 来安装 flatpak。
|
||||||
|
|
||||||
```
|
```
|
||||||
$ sudo pacman -S flatpak
|
$ sudo pacman -S flatpak
|
||||||
```
|
```
|
||||||
|
|
||||||
For **`RHEL/CentOS`** systems, use **[YUM Command][12]** to install flatpak.
|
对于 **`RHEL/CentOS`** 系统,使用 **[YUM 命令][12]** 来安装 flatpak。
|
||||||
|
|
||||||
```
|
```
|
||||||
$ sudo yum install flatpak
|
$ sudo yum install flatpak
|
||||||
```
|
```
|
||||||
|
|
||||||
For **`openSUSE Leap`** system, use **[Zypper Command][13]** to install flatpak.
|
对于 **`openSUSE Leap`** 系统,使用 **[Zypper 命令][13]** 来安装 flatpak。
|
||||||
|
|
||||||
```
|
```
|
||||||
$ sudo zypper install flatpak
|
$ sudo zypper install flatpak
|
||||||
```
|
```
|
||||||
|
|
||||||
### How To Enable Flathub Support On Linux?
|
### 如何在 Linux 上启用 Flathub 支持?
|
||||||
|
|
||||||
Flatbub website is a app store for Flatpak packages where you can find them.
|
Flathub 网站是一个应用程序商店,你可以在其中找到 flatpak。
|
||||||
|
|
||||||
It’s a central repository where all the flatpak applications are available for users.
|
它是一个中央仓库,所有的 flatpak 应用程序都可供用户使用。
|
||||||
|
|
||||||
Run the following command to enable Flathub support on Linux.
|
运行以下命令在 Linux 上启用 Flathub 支持:
|
||||||
|
|
||||||
```
|
```
|
||||||
$ sudo flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
|
$ sudo flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
|
||||||
```
|
```
|
||||||
|
|
||||||
Install the Software Flatpak plugin for GNOME Desktop Environment.
|
为 GNOME 桌面环境安装 Software Flatpak 插件。
|
||||||
|
|
||||||
```
|
```
|
||||||
$ sudo apt install gnome-software-plugin-flatpak
|
$ sudo apt install gnome-software-plugin-flatpak
|
||||||
```
|
```
|
||||||
|
|
||||||
Also, you can enable GNOME Repository if you are using GNOME Desktop Environment. It’s containing all GNOME core applications.
|
此外,如果你使用的是 GNOME 桌面环境,则可以启用 GNOME 仓库。它包含所有 GNOME 核心应用程序。
|
||||||
|
|
||||||
```
|
```
|
||||||
$ wget https://sdk.gnome.org/keys/gnome-sdk.gpg
|
$ wget https://sdk.gnome.org/keys/gnome-sdk.gpg
|
||||||
$ sudo flatpak remote-add --gpg-import=gnome-sdk.gpg --if-not-exists gnome-apps https://sdk.gnome.org/repo-apps/
|
$ sudo flatpak remote-add --gpg-import=gnome-sdk.gpg --if-not-exists gnome-apps https://sdk.gnome.org/repo-apps/
|
||||||
```
|
```
|
||||||
|
|
||||||
### How To List configured flatpak repositories?
|
### 如何列出已配置的 flakpak 仓库?
|
||||||
|
|
||||||
Run the following command, if you would like to view list of the configured flatpak repositories on your system.
|
如果要查看系统上已配置的 flatpak 仓库列表,运行以下命令:
|
||||||
|
|
||||||
```
|
```
|
||||||
$ flatpak remotes
|
$ flatpak remotes
|
||||||
@ -131,9 +130,9 @@ flathub system
|
|||||||
gnome-apps system
|
gnome-apps system
|
||||||
```
|
```
|
||||||
|
|
||||||
### How To List The Available Packages In The Configured Repositories?
|
### 如何列出已配置仓库中的可用软件包?
|
||||||
|
|
||||||
Run the following command, if you would like to view list of the available packages (It will display all together like, applications and run times) in the configured repositories.
|
如果要查看已配置仓库中的可用软件包的列表(它将显示所有软件包,如应用程序和运行环境),运行以下命令:
|
||||||
|
|
||||||
```
|
```
|
||||||
$ flatpak remote-ls | head -10
|
$ flatpak remote-ls | head -10
|
||||||
@ -150,21 +149,21 @@ org.gnome.Documents gnome-apps
|
|||||||
org.gnome.Epiphany gnome-apps
|
org.gnome.Epiphany gnome-apps
|
||||||
```
|
```
|
||||||
|
|
||||||
To list only applications not runtimes.
|
仅列出应用程序:
|
||||||
|
|
||||||
```
|
```
|
||||||
$ flatpak remote-ls --app
|
$ flatpak remote-ls --app
|
||||||
```
|
```
|
||||||
|
|
||||||
To list specific repository applications.
|
列出特定的仓库应用程序:
|
||||||
|
|
||||||
```
|
```
|
||||||
$ flatpak remote-ls gnome-apps
|
$ flatpak remote-ls gnome-apps
|
||||||
```
|
```
|
||||||
|
|
||||||
### How To Install A Package From flatpak?
|
### 如何从 flatpak 安装包?
|
||||||
|
|
||||||
Run the following command to install a package from flatpak repository.
|
运行以下命令从 flatpak 仓库安装软件包:
|
||||||
|
|
||||||
```
|
```
|
||||||
$ sudo flatpak install flathub com.github.muriloventuroso.easyssh
|
$ sudo flatpak install flathub com.github.muriloventuroso.easyssh
|
||||||
@ -198,24 +197,24 @@ Installing: com.github.muriloventuroso.easyssh.Locale/x86_64/stable from flathub
|
|||||||
Now at af837356b222.
|
Now at af837356b222.
|
||||||
```
|
```
|
||||||
|
|
||||||
All the installed application will be placed in the following location.
|
所有已安装的应用程序都将放在以下位置:
|
||||||
|
|
||||||
```
|
```
|
||||||
$ ls /var/lib/flatpak/app/
|
$ ls /var/lib/flatpak/app/
|
||||||
com.github.muriloventuroso.easyssh
|
com.github.muriloventuroso.easyssh
|
||||||
```
|
```
|
||||||
|
|
||||||
### How To Run The Installed Application?
|
### 如何运行已安装的应用程序?
|
||||||
|
|
||||||
Run the following command to launch the required application. Make sure, you have to replace with your application name instead.
|
运行以下命令以启动所需的应用程序,确保替换为你的应用程序名称:
|
||||||
|
|
||||||
```
|
```
|
||||||
$ flatpak run com.github.muriloventuroso.easyssh
|
$ flatpak run com.github.muriloventuroso.easyssh
|
||||||
```
|
```
|
||||||
|
|
||||||
### How To View The Installed Application?
|
### 如何查看已安装的应用程序?
|
||||||
|
|
||||||
Run the following command to view the installed application.
|
运行以下命令来查看已安装的应用程序:
|
||||||
|
|
||||||
```
|
```
|
||||||
$ flatpak list
|
$ flatpak list
|
||||||
@ -225,9 +224,9 @@ org.freedesktop.Platform.html5-codecs/x86_64/18.08 system,runtime
|
|||||||
org.gnome.Platform/x86_64/3.30 system,runtime
|
org.gnome.Platform/x86_64/3.30 system,runtime
|
||||||
```
|
```
|
||||||
|
|
||||||
### How To View The Detailed Information About The Installed Application?
|
### 如何查看有关已安装应用程序的详细信息?
|
||||||
|
|
||||||
Run the following command to view the detailed information about the installed application.
|
运行以下命令以查看有关已安装应用程序的详细信息。
|
||||||
|
|
||||||
```
|
```
|
||||||
$ flatpak info com.github.muriloventuroso.easyssh
|
$ flatpak info com.github.muriloventuroso.easyssh
|
||||||
@ -248,29 +247,28 @@ Runtime: org.gnome.Platform/x86_64/3.30
|
|||||||
Sdk: org.gnome.Sdk/x86_64/3.30
|
Sdk: org.gnome.Sdk/x86_64/3.30
|
||||||
```
|
```
|
||||||
|
|
||||||
### How To Update The Installed Application?
|
### 如何更新已安装的应用程序?
|
||||||
|
|
||||||
Run the following command to updated the installed application to latest version.
|
运行以下命令将已安装的应用程序更新到最新版本:
|
||||||
|
|
||||||
```
|
```
|
||||||
$ flatpak update
|
$ flatpak update
|
||||||
```
|
```
|
||||||
|
|
||||||
For specific application, use the following format.
|
对于特定应用程序,使用以下格式:
|
||||||
|
|
||||||
```
|
```
|
||||||
$ flatpak update com.github.muriloventuroso.easyssh
|
$ flatpak update com.github.muriloventuroso.easyssh
|
||||||
```
|
```
|
||||||
|
|
||||||
### How To Remove The Installed Application?
|
### 如何移除已安装的应用程序?
|
||||||
|
|
||||||
Run the following command to remove the installed application.
|
|
||||||
|
|
||||||
|
运行以下命令来移除已安装的应用程序:
|
||||||
```
|
```
|
||||||
$ sudo flatpak uninstall com.github.muriloventuroso.easyssh
|
$ sudo flatpak uninstall com.github.muriloventuroso.easyssh
|
||||||
```
|
```
|
||||||
|
|
||||||
Go to the man page for more details and options.
|
进入 man 页面以获取更多细节和选项:
|
||||||
|
|
||||||
```
|
```
|
||||||
$ flatpak --help
|
$ flatpak --help
|
||||||
@ -282,7 +280,7 @@ via: https://www.2daygeek.com/how-to-install-and-enable-flatpak-support-on-linux
|
|||||||
|
|
||||||
作者:[Magesh Maruthamuthu][a]
|
作者:[Magesh Maruthamuthu][a]
|
||||||
选题:[lujun9972][b]
|
选题:[lujun9972][b]
|
||||||
译者:[译者ID](https://github.com/译者ID)
|
译者:[MjSeven](https://github.com/MjSeven)
|
||||||
校对:[校对者ID](https://github.com/校对者ID)
|
校对:[校对者ID](https://github.com/校对者ID)
|
||||||
|
|
||||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
|
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
|
Loading…
Reference in New Issue
Block a user