Merge remote-tracking branch 'LCTT/master'

2025-01-13 22:30:37 +08:00 · 2020-01-11 22:31:22 +08:00 · 2020-01-11 22:31:22 +08:00 · 2fc612bad9
commit 2fc612bad9
parent 013a5a3b66 b00f1e8aba
4 changed files with 354 additions and 367 deletions
--- a/sources/tech/20190406
+++ b/sources/tech/20190406
@ -1,240 +0,0 @@
 [#]: collector: (lujun9972)
 [#]: translator: (wxy)
 [#]: reviewer: ( )
 [#]: publisher: ( )
 [#]: url: ( )
 [#]: subject: (Run a server with Git)
 [#]: via: (https://opensource.com/article/19/4/server-administration-git)
 [#]: author: (Seth Kenlon  https://opensource.com/users/seth/users/seth)
 Run a server with Git
 ======
 Thanks to Gitolite, you can manage a Git server with Git. Learn how in
 our series about little-known Git uses.
 ![computer servers processing data][1]
 As I've tried to demonstrate in this series leading up to Git's 14th anniversary on April 7, [Git][2] can do a wide range of things beyond tracking source code. Believe it or not, Git can even manage your Git server, so you can, more or less, run a Git server with Git itself.
 Of course, this involves a lot of components beyond everyday Git, not the least of which is [Gitolite][3], the backend application managing the fiddly bits that you configure using Git. The great thing about Gitolite is that, because it uses Git as its frontend interface, it's easy to integrate Git server administration within the rest of your Git-based workflow. Gitolite provides precise control over who can access specific repositories on your server and what permissions they have. You can manage that sort of thing yourself with the usual Linux system tools, but it takes a lot of work if you have more than just one or two repos across a half-dozen users.
 Gitolite's developers have done the hard work to make it easy for you to provide many users with access to your Git server without giving them access to your entire environment—and you can do it all with Git.
 What Gitolite is _not_ is a GUI admin and user panel. That sort of experience is available with the excellent [Gitea][4] project, but this article focuses on the simple elegance and comforting familiarity of Gitolite.
 ### Install Gitolite
 Assuming your Git server runs Linux, you can install Gitolite with your package manager ( **yum** on CentOS and RHEL, **apt** on Debian and Ubuntu, **zypper** on OpenSUSE, and so on). For example, on RHEL:
 ```
 `$ sudo yum install gitolite3`
 ```
 Many repositories still have older versions of Gitolite for legacy support, but the current version is version 3.
 You must have passwordless SSH access to your server. You can use a password to log in if you prefer, but Gitolite relies on SSH keys, so you must configure the option to log in with keys. If you don't know how to configure a server for passwordless SSH access, go learn how to do that first (the [Setting up SSH key authentication][5] section of Steve Ovens's Ansible article explains it well). It's an essential part of secure server administration—as well as of running Gitolite.
 ### Configure a Git user
 Without Gitolite, if a person requests access to a Git repository you host on a server, you have to provide that person with a user account. Git provides a special shell, the **git-shell** , which is an ultra-specific shell that performs only Git tasks. This lets you have users who can access your server only through the filter of a very limited shell environment.
 That solution works, but it usually means a user gains access to all repositories on your server unless you have a very good schema for group permissions and maintain those permissions strictly whenever a new repository is created. It also requires a lot of manual configuration at the system level, an area usually reserved for a specific tier of sysadmins and not necessarily the person usually in charge of Git repositories.
 Gitolite sidesteps this issue entirely by designating one username for every person who needs access to any repository. By default, the username is **git** , and because Gitolite's documentation assumes that's what is used, it's a good default to keep when you're learning the tool. It's also a well-known convention for anyone who's ever used GitLab or GitHub or any other Git hosting service.
 Gitolite calls this user the _hosting user_. Create an account on your server to act as the hosting user (I'll stick with **git** because that's the convention):
 ```
 ` $ sudo adduser --create-home git`
 ```
 For you to control the **git** user account, it must have a valid public SSH key that belongs to you. You should already have this set up, so **cp** your public key ( _not your private key_ ) to the **git** user's home directory:
 ```
 $ sudo cp ~/.ssh/id_ed25519.pub /home/git/
 $ sudo chown git:git /home/git/id_ed25519.pub
 ```
 If your public key doesn't end with the extension **.pub** , Gitolite will not use it, so rename the file accordingly. Change to that user account to run Gitolite's setup:
 ```
 $ sudo su - git
 $ gitolite setup --pubkey id_ed25519.pub
 ```
 After the setup script runs, the **git** home's user directory will have a **repositories** directory, which (for now) contains the files **git-admin.git** and **testing.git**. That's all the setup the server requires, so log out.
 ### Use Gitolite
 Managing Gitolite is a matter of editing text files in a Git repository, specifically **gitolite-admin.git**. You won't SSH into your server for Git administration, and Gitolite encourages you not to try. The repositories you and your users store on the Gitolite server are _bare_ repositories, so it's best to stay out of them.
 ```
 $ git clone [git@example.com][6]:gitolite-admin.git gitolite-admin.git
 $ cd gitolite-admin.git
 $ ls -1
 conf
 keydir
 ```
 The **conf** directory in this repository contains a file called **gitolite.conf**. Open it in a text editor or use **cat** to view its contents:
 ```
 repo gitolite-admin
 RW+ = id_ed22519
 repo testing
 RW+ = @all
 ```
 You may have an idea of what this configuration file does: **gitolite-admin** represents this repository, and the owner of the **id_ed25519** key has read, write, and Git administrative privileges. In other words, rather than mapping users to normal local Unix users (because all your users log in using the **git** hosting user identity), Gitolite maps users to SSH keys listed in the **keydir** directory.
 The **testing.git** repository gives full permissions to everyone with access to the server using special group notation.
 #### Add users
 If you want to add a user called **alice** to your Git server, the person Alice must send you her public SSH key. Gitolite uses whatever is to the left of the **.pub** extension as the identifier for your Git users. Rather than using the default key name values, give keys a name indicative of the key owner. If a user has more than one key (e.g., one for her laptop, one for her desktop), you can use subdirectories to avoid file name collisions. For instance, the key Alice uses from her laptop might come to you as the default **id_rsa.pub** , so rename it **alice.pub** or similar (or let the users name the key according to their local user accounts on their computers), and place it into the **gitolite-admin.git/keydir/work/laptop/** directory. If she sends you another key from her desktop, name it **alice.pub** (the same as the previous one) and add it to **keydir/work/desktop/**. Another key might go into **keydir/home/desktop/** , and so on. Gitolite recursively searches **keydir** for a **.pub** file matching a repository "user" and treats any match as the same identity.
 When you add keys to the **keydir** directory, you must commit them back to your server. This is such an easy thing to forget that there's a real argument here for using an automated Git application like [**Sparkleshare**][7] so any change is committed back to your Gitolite admin immediately. The first time you forget to commit and push—and waste three hours of your time and your user's time troubleshooting—you'll see that Gitolite is the perfect justification for using Sparkleshare.
 ```
 $ git add keydir
 $ git commit -m 'added alice-laptop-0.pub'
 $ git push origin HEAD
 ```
 Alice, by default, gains access to the **testing.git** directory so she can test connectivity and functionality with that.
 #### Set permissions
 As with users, directory permissions and groups are abstracted away from the normal Unix tools you might be used to (or find information about online). Permissions to projects are granted in the **gitolite.conf** file in **gitolite-admin.git/conf** directory. There are four levels of permissions:
  * **R** allows read-only. A user with **R** permissions on a repository may clone it, and that's all.
  * **RW** allows a user to perform a fast-forward push of a branch, create new branches, and create new tags. More or less, this one feels like a "normal" Git repository to most users.
  * **RW+** allows Git actions that are potentially destructive. A user can perform normal fast-forward pushes, as well as rewind pushes, do rebases, and delete branches and tags. This may or may not be something you want to grant to all contributors on a project.
  * **-** explicitly denies access to a repository. This is essentially the same as a user not being listed in the repository's configuration.
 Create a new repository or modify an existing repository's permissions by adjusting **gitolite.conf**. For instance, to give Alice permissions to administrate a new repository called **widgets.git** :
 ```
 repo gitolite-admin
 RW+ = id_ed22519
 repo testing
 RW+ = @all
 repo widgets
 RW+ = alice
 ```
 Now Alice—and Alice alone—can clone the repo:
 ```
 [alice]$ git clone [git@example.com][6]:widgets.git
 Cloning into 'widgets'...
 warning: You appear to have cloned an empty repository.
 ```
 On her initial push, Alice must use the **-u** option to send her branch to the empty repository (as she would have to do with any Git host).
 To make user management easier, you can define groups of repositories:
 ```
@qtrepo = widgets
@qtrepo = games
 repo gitolite-admin
 RW+ = id_ed22519
 repo testing
 RW+ = @all
 repo @qtrepo
 RW+ = alice
 ```
 Just as you can create group repositories, you can group users. One user group exists by default: **@all**. As you might expect, it includes all users, without exception. You can create your own:
 ```
@qtrepo = widgets
@qtrepo = games
@developers = alice bob
 repo gitolite-admin
 RW+ = id_ed22519
 repo testing
 RW+ = @all
 repo @qtrepo
 RW+ = @developers
 ```
 As with adding or modifying key files, any change to the **gitolite.conf** file must be committed and pushed to take effect.
 ### Create a repository
 By default, Gitolite assumes repository creation happens from the top down. For instance, a project manager with access to the Git server creates a project repository and, through the Gitolite administration repo, adds developers.
 In practice, you might prefer to grant users permission to create repositories. Gitolite calls these "wild repos" (I'm not sure whether that's commentary on how the repos come into being or a reference to the wildcard characters required by the configuration file to let it happen). Here's an example:
 ```
@managers = alice bob
 repo foo/CREATOR/[a-z]..*
 C = @managers
 RW+ = CREATOR
 RW = WRITERS
 R = READERS
 ```
 The first line defines a group of users: the group is called **@managers** and contains users **alice** and **bob**. The next line sets up a wildcard allowing repositories that do not yet exist to be created in a directory called **foo** followed by a subdirectory named for the user creating the repo. For example:
 ```
 [alice]$ git clone [git@example.com][6]:foo/alice/cool-app.git
 Cloning into cool-app'...
 Initialized empty Git repository in /home/git/repositories/foo/alice/cool-app.git
 warning: You appear to have cloned an empty repository.
 ```
 There are some mechanisms for the creator of a wild repo to define who can read and write to their repository, but they're limited in scope. For the most part, Gitolite assumes that a specific set of users governs project permission. One solution is to grant all users access to **gitolite-admin** using a Git hook to require manager approval to merge changes into the master branch.
 ### Learn more
 Gitolite has many more features than what this introductory article covers, so try it out. The [documentation][8] is excellent, and once you read through it, you can customize your Gitolite server to provide your users whatever level of control you are comfortable with. Gitolite is a low-maintenance, simple system that you can install, set up, and then more or less forget about.
 --------------------------------------------------------------------------------
 via: https://opensource.com/article/19/4/server-administration-git
 作者：[Seth Kenlon (Red Hat, 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/seth/users/seth
 [b]: https://github.com/lujun9972
 [1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/server_data_system_admin.png?itok=q6HCfNQ8 (computer servers processing data)
 [2]: https://git-scm.com/
 [3]: http://gitolite.com
 [4]: http://gitea.io
 [5]: Setting%20up%20SSH%20key%20authentication
 [6]: mailto:git@example.com
 [7]: https://opensource.com/article/19/4/file-sharing-git
 [8]: http://gitolite.com/gitolite/quick_install.html
--- a/sources/tech/20200107
+++ b/sources/tech/20200107
@ -1,127 +0,0 @@
 [#]: collector: (lujun9972)
 [#]: translator: (heguangzhi)
 [#]: reviewer: ( )
 [#]: publisher: ( )
 [#]: url: ( )
 [#]: subject: (How piwheels will save Raspberry Pi users time in 2020)
 [#]: via: (https://opensource.com/article/20/1/piwheels)
 [#]: author: (Ben Nuttall https://opensource.com/users/bennuttall)
 How piwheels will save Raspberry Pi users time in 2020
 ======
 By making pre-compiled Python packages for Raspberry Pi available, the
 piwheels project saves users significant time and effort.
 ![rainbow colors on pinwheels in the sun][1]
 Piwheels automates building Python wheels (pre-compiled Python packages) for all of the projects on [PyPI][2], the Python Package Index, using Raspberry Pi hardware to ensure compatibility. This means that when a Raspberry Pi user wants to install a Python library using **pip**, they get a ready-made compiled version that's guaranteed to work on the Raspberry Pi. This makes it much easier for Raspberry Pi users to dive in and get started with their projects.
 ![Piwheels logo][3]
 When I wrote [_piwheels: Speedy Python package installation for the Raspberry Pi_][4] in October 2018, the piwheels project was in its first year and already proving its purpose of saving Raspberry Pi users considerable time and effort. But the project, which makes pre-compiled Python packages available for Raspberry Pi, has come a long way in its second year.
 ![Raspberry Pi 4][5]
 ### How it works
 [Raspbian][6], the primary OS for Raspberry Pi, comes pre-configured to use piwheels, so users don't need to do anything special to get access to the wheels.
 The configuration file (at **/etc/pip.conf**) tells pip to use [piwheels.org][7] as an _additional index_, so pip looks at PyPI first, then piwheels. The Piwheels website is hosted on a Raspberry Pi 3, and all the wheels built by the project are hosted on that Pi. It serves over 1 million packages per month—not bad for a $35 computer!
 In addition to the main Raspberry Pi that serves the website, the piwheels project uses seven other Pis to build the packages. Some run Raspbian Jessie, building wheels for Python 3.4, some run Raspbian Stretch for Python 3.5, and some run Raspbian Buster for Python 3.7. The project doesn't generally support other Python versions. There's also a "proper server"—a virtual machine running the Postgres database. Since the Pi 3 has just 1GB of RAM, the (very large) database doesn't run well on it, so we moved it to a VM. The Pi 4 with 4GB RAM would probably be suitable, so we may move to this in the future.
 The Pis are all on an IPv6-only network in a "Pi Cloud"—a brilliant service provided by Cambridge-based hosting company [Mythic Beasts][8].
 ![Mythic Beasts hosting service][9]
 ### Downloads and trends
 Every time a wheel file is downloaded, it is logged in the database. This provides insight into what packages are most popular and what Python versions and operating systems people are using. We don't have much information from the user agent, but because the architecture of Pi 1/Zero shows as "armv6" and Pi 2/3/4 show as "armv7," we can tell them apart.
 As of mid-December 2019, over 14 million packages have been downloaded from piwheels, with nearly 9 million in 2019 alone.
 The 10 most popular packages since the project's inception are:
  1. [pycparser][10] (821,060 downloads)
  2. [PyYAML][11] (366,979)
  3. [numpy][12] (354,531)
  4. [cffi][13] (336,982)
  5. [MarkupSafe][14] (318,878)
  6. [future][15] (282,349)
  7. [aiohttp][16] (277,046)
  8. [cryptography][17] (276,167)
  9. [home-assistant-frontend][18] (266,667)
  10. [multidict][19] (256,185)
 Note that many pure-Python packages, such as [urllib3][20], are provided as wheels on PyPI; because these are compatible across platforms, they're not usually downloaded from piwheels because PyPI takes precedence.
 We also see trends in things like which Python versions are used over time. This shows the quick takeover of Python 3.7 from 3.5 when Raspbian Buster was released:
 ![Data from piwheels on Python versions used over time][21]
 You can see more trends in our [stats blog posts][22].
 ### Time saved
 Every package build is logged in the database, and every download is also stored. Cross-referencing downloads with build duration shows how much time has been saved. One example is numpy—the latest version took about 11 minutes to build.
 So far, piwheels has saved users a total of over 165 years of build time. At the current usage rate, piwheels saves _over 200 days per day_.
 As well as saving build time, having pre-compiled wheels also means people don't have to install various development tools to build packages. Some packages require other apt packages for them to access shared libraries. Figuring out which ones you need can be a pain, so we made that step easier, too. First, we figured out the process and [documented it on our blog][23]. Then we added this logic to the build process so that when a wheel is built, its dependencies are automatically calculated and added to the package's project page:
 ![numpy dependencies][24]
 ### What next for piwheels?
 We launched project pages (e.g., [numpy][25]) this year, which are a really useful way to let people look up information about a project in a human-readable way. They also make it easier for people to report issues, such as if a project is missing from piwheels or they have an issue with a package they've downloaded.
 In early 2020, we're planning to roll out some upgrades to piwheels that will enable a new JSON API, so you can automatically check which versions are available, look up dependencies for a project, and lots more.
 The next Debian/Raspbian upgrade won't happen until mid-2021, so we won't start building wheels for any new Python versions until then.
 You can read more about piwheels on the project's [blog][26], where I'll be publishing a 2019 roundup early in 2020. You can also follow [@piwheels][27] on Twitter, where you'll see daily and monthly stats along with any milestones reached.
 Of course, piwheels is an open source project, and you can see the entire project [source code on GitHub][28].
 --------------------------------------------------------------------------------
 via: https://opensource.com/article/20/1/piwheels
 作者：[Ben Nuttall][a]
 选题：[lujun9972][b]
 译者：[heguangzhi](https://github.com/heguangzhi)
 校对：[校对者ID](https://github.com/校对者ID)
 本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
 [a]: https://opensource.com/users/bennuttall
 [b]: https://github.com/lujun9972
 [1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/rainbow-pinwheel-piwheel-diversity-inclusion.png?itok=di41Wd3V (rainbow colors on pinwheels in the sun)
 [2]: https://pypi.org/
 [3]: https://opensource.com/sites/default/files/uploads/piwheels.png (Piwheels logo)
 [4]: https://opensource.com/article/18/10/piwheels-python-raspberrypi
 [5]: https://opensource.com/sites/default/files/uploads/raspberry-pi-4_0.jpg (Raspberry Pi 4)
 [6]: https://www.raspberrypi.org/downloads/raspbian/
 [7]: http://piwheels.org
 [8]: https://www.mythic-beasts.com/order/rpi
 [9]: https://opensource.com/sites/default/files/uploads/pi-cloud.png (Mythic Beasts hosting service)
 [10]: https://www.piwheels.org/project/pycparser
 [11]: https://www.piwheels.org/project/PyYAML
 [12]: https://www.piwheels.org/project/numpy
 [13]: https://www.piwheels.org/project/cffi
 [14]: https://www.piwheels.org/project/MarkupSafe
 [15]: https://www.piwheels.org/project/future
 [16]: https://www.piwheels.org/project/aiohttp
 [17]: https://www.piwheels.org/project/cryptography
 [18]: https://www.piwheels.org/project/home-assistant-frontend
 [19]: https://www.piwheels.org/project/multidict
 [20]: https://piwheels.org/project/urllib3/
 [21]: https://opensource.com/sites/default/files/uploads/pyvers2019.png (Data from piwheels on Python versions used over time)
 [22]: https://blog.piwheels.org/piwheels-stats-for-2019/
 [23]: https://blog.piwheels.org/how-to-work-out-the-missing-dependencies-for-a-python-package/
 [24]: https://opensource.com/sites/default/files/uploads/numpy-deps.png (numpy dependencies)
 [25]: https://www.piwheels.org/project/numpy/
 [26]: https://blog.piwheels.org/
 [27]: https://twitter.com/piwheels
 [28]: https://github.com/piwheels/
--- a/translated/tech/20190406
+++ b/translated/tech/20190406
@ -0,0 +1,226 @@
 [#]: collector: (lujun9972)
 [#]: translator: (wxy)
 [#]: reviewer: ( )
 [#]: publisher: ( )
 [#]: url: ( )
 [#]: subject: (Run a server with Git)
 [#]: via: (https://opensource.com/article/19/4/server-administration-git)
 [#]: author: (Seth Kenlon  https://opensource.com/users/seth/users/seth)
 使用 Git 来管理 Git 服务器
 ======
 > 借助 Gitolite，你可以使用 Git 来管理 Git 服务器。在我们的系列中了解这些鲜为人知的 Git 用途。
 ![computer servers processing data][1]
 正如我在系列文章中演示的那样，[Git][2] 除了跟踪源代码外，还可以做很多事情。信不信由你，Git 甚至可以管理你的 Git 服务器，因此你可以或多或少地使用 Git 本身运行 Git 服务器。
 当然，这涉及除日常使用 Git 之外的许多组件，其中最重要的是 [Gitolite][3]，该后端应用程序可以管理你使用 Git 的每个细小的配置。Gitolite 的优点在于，由于它使用 Git 作为其前端接口，因此很容易将 Git 服务器管理集成到其他基于 Git 的工作流中。Gitolite 可以精确控制谁可以访问你服务器上的特定存储库以及他们具有哪些权限。你可以使用常规的 Linux 系统工具自行管理此类事务，但是如果在六个用户中只有一个或两个以上的仓库，则需要大量的工作。
 Gitolite 的开发人员做了艰苦的工作，使你可以轻松地为许多用户提供对你的 Git 服务器的访问权，而又不让他们访问你的整个环境 —— 而这一切，你可以使用 Git 来完成全部工作。
 Gitolite 并`不是` 图形化的管理员和用户面板。优秀的 [Gitea][4] 项目可提供这种经验，但是本文重点介绍 Gitolite 的简单优雅和令人舒适的熟悉感。
 ### 安装 Gitolite
 假设你的 Git 服务器运行 Linux，则可以使用包管理器安装 Gitolite（在 CentOS 和 RHEL 上为 `yum`，在 Debian 和 Ubuntu 上为 `apt`，在 OpenSUSE 上为 `zypper` 等）。例如，在 RHEL 上：
 ```
 $ sudo yum install gitolite3
 ```
 许多发行版的存储库仍提供的是旧版本的 Gitolite，但当前版本为版本 3。
 你必须具有对服务器的无密码 SSH 访问权限。如果愿意，你可以使用密码登录服务器，但是 Gitolite 依赖于 SSH 密钥，因此必须配置使用密钥登录的选项。如果你不知道如何配置服务器以进行无密码 SSH 访问，请首先学习如何进行操作（Steve Ovens 的 Ansible 文章的[设置 SSH 密钥身份验证][5]部分对此进行了很好的说明）。这是加强服务器管理的安全以及运行 Gitolite 的重要组成部分。
 ### 配置 Git 用户
 如果没有 Gitolite，则如果某人请求访问你在服务器上托管的 Git 存储库，则必须向该人提供用户帐户。Git 提供了一个特殊的外壳，即 `git-shell`，这是一个仅执行 Git 任务的特别特定的 shell。这可以让你有个只能通过非常受限的 Shell 环境的过滤器来访问服务器的用户。
 该解决方案可行，但通常意味着用户可以访问服务器上的所有存储库，除非你具有用于组权限的良好模式，并在创建新存储库时严格保持这些权限。这种方式还需要在系统级别进行大量手动配置，这通常是为特定级别的系统管理员保留的区域，而不一定是通常负责 Git 存储库的人员。
 Gitolite 通过为需要访问任何存储库的每个人指定一个用户名来完全回避此问题。 默认情况下，用户名是 `git`，并且由于 Gitolite 的文档假定使用的是它，因此在学习该工具时保留它是一个很好的默认设置。对于曾经使用过 GitLab 或 GitHub 或任何其他 Git 托管服务的人来说，这也是一个众所周知的约定。
 Gitolite 将此用户称为**托管用户**。在服务器上创建一个帐户以充当托管用户（我习惯使用 `git`，因为这是惯例）：
 ```
 $ sudo adduser --create-home git
 ```
 为了控制该 `git` 用户帐户，该帐户必须具有属于你的有效 SSH 公钥。你应该已经进行了设置，因此复制你的公钥（**不是你的私钥**）添加到 `git` 用户的家目录中：
 ```
 $ sudo cp ~/.ssh/id_ed25519.pub /home/git/
 $ sudo chown git:git /home/git/id_ed25519.pub
 ```
 如果你的公钥不以扩展名 `.pub` 结尾，则 Gitolite 不会使用它，因此请相应地重命名该文件。切换为该用户帐户以运行 Gitolite 的安装程序：
 ```
 $ sudo su - git
 $ gitolite setup --pubkey id_ed25519.pub
 ```
 安装脚本运行后，`git` 的家用户目录将有一个 `repository` 目录，该目录（目前）包含文件 `git-admin.git` 和 `testing.git`。这就是该服务器所需的全部设置，现在请登出 `git` 用户。 
 ### 使用 Gitolite
 管理 Gitolite 就是编辑 Git 存储库中的文本文件，尤其是 `gitolite-admin.git`。你不会通过 SSH 进入服务器来进行 Git 管理，并且 Gitolite 也建议你不要这样尝试。你和你的用户存储在 Gitolite 服务器上的存储库是个**裸**存储库，因此最好不要使用它们。
 ```
 $ git clone git@example.com:gitolite-admin.git gitolite-admin.git
 $ cd gitolite-admin.git
 $ ls -1
 conf
 keydir
 ```
 该存储库中的 `conf` 目录包含一个名为 `gitolite.conf` 的文件。在文本编辑器中打开它，或使用`cat`查看其内容：
 ```
 repo gitolite-admin
    RW+     =   id_ed22519
 repo testing
    RW+     =   @all
 ```
 你可能对该配置文件的功能有所了解：`gitolite-admin` 代表此存储库，并且 `id_ed25519` 密钥的所有者具有读取、写入和 Git 管理权限。换句话说，不是将用户映射到普通的本地 Unix 用户（因为所有用户都使用 `git` 用户托管用户身份），而是将用户映射到 `keydir` 目录中列出的 SSH 密钥。
 `testing.git` 存储库使用特殊组符号为访问服务器的每个人提供了全部权限。
 #### 添加用户
 如果要向 Git 服务器添加一个名为 `alice` 的用户，Alice 必须向你发送她的 SSH 公钥。Gitolite 使用 `.pub` 扩展名左边的任何内容作为该 Git 用户的标识符。不要使用默认的密钥名称值，而是给密钥指定一个指示密钥所有者的名称。如果用户有多个密钥（例如，一个用于笔记本电脑，一个用于台式机），则可以使用子目录来避免文件名冲突。例如，Alice 在笔记本电脑上使用的密钥可能是默认的 `id_rsa.pub`，因此将其重命名为`alice.pub` 或类似名称（或让用户根据其计算机上的本地用户帐户来命名密钥），然后将其放入 `gitolite-admin.git/keydir/work/laptop/` 目录中。如果她从她的桌面发送了另一个密钥，命名为 `alice.pub`（与上一个相同），然后将其添加到 `keydir/home/desktop/` 中。另一个密钥可能放到 `keydir/home/desktop/` 中，依此类推。Gitolite 递归地在 `keydir` 中搜索与存储库“用户”匹配的 `.pub` 文件，并将所有匹配项视为相同的身份。
 当你将密钥添加到 `keydir` 目录时，必须将它们提交回服务器。这是一件很容易忘记的事情，这里有一个使用自动化的 Git 应用程序（例如 [Sparkleshare] [7]）的真正的理由，因此任何更改都将立即提交给你的 Gitolite 管理员。第一次忘记提交和推送，在浪费了三个小时的时间以及用户的故障排除时间之后，你会发现 Gitolite 是使用 Sparkleshare 的完美理由。
 ```
 $ git add keydir
 $ git commit -m 'added alice-laptop-0.pub'
 $ git push origin HEAD
 ```
 默认情况下，Alice 可以访问 `testing.git` 目录，因此她可以使用该目录测试连接性和功能。
 #### 设置权限
 与用户一样，目录权限和组也是从你可能习惯的的常规 Unix 工具中抽象出来的（或可从在线信息查找）。在`gitolite-admin.git/conf` 目录中的 `gitolite.conf` 文件中授予对项目的权限。权限分为四个级别：
 * `R` 允许只读。在存储库上具有 `R` 权限的用户可以克隆它，仅此而已。
 * `RW` 允许用户执行分支的快进推送、创建新分支和创建新标签。对于大多数用户来说，这个或多或少感觉就像一个“普通”的 Git 存储库。
 * `RW+` 允许可能具有破坏性的 Git 动作。用户可以执行常规的快进推送、回滚推送、变基以及删除分支和标签。你可能想要或不希望将其授予项目中的所有贡献者。
 * `-` 明确拒绝访问存储库。这与未在存储库的配置中列出的用户相同。
 通过调整 `gitolite.conf` 来创建一个新的存储库或修改现有存储库的权限。例如，授予 Alice 权限来管理一个名为 `widgets.git` 的新存储库：
 ```
 repo gitolite-admin
    RW+     =   id_ed22519
 repo testing
    RW+     =   @all
 repo widgets
    RW+     =   alice
 ```
 现在，Alice（也仅 Alice 一个人）就可以克隆该存储库：
 ```
 [alice]$ git clone git@example.com:widgets.git
 Cloning into 'widgets'...
 warning: You appear to have cloned an empty repository.
 ```
 在第一次推送时，Alice 必须使用 `-u` 选项将其分支发送到空存储库（如同她在任何 Git 主机上做的一样）。
 为了简化用户管理，你可以定义存储库组：
 ```
@qtrepo = widgets
@qtrepo = games
 repo gitolite-admin
    RW+     =   id_ed22519
 repo testing
    RW+     =   @all
 repo @qtrepo
    RW+     =   alice
 ```
 正如你可以创建组存储库一样，你也可以对用户进行分组。默认情况下存在一个用户组：`@all`。如你所料，它包括所有用户，无一例外。你也可以创建自己的组：
 ```
@qtrepo = widgets
@qtrepo = games
@developers = alice bob
 repo gitolite-admin
    RW+     =   id_ed22519
 repo testing
    RW+     =   @all
 repo @qtrepo
    RW+     =   @developers
 ```
 与添加或修改密钥文件一样，对 `gitolite.conf` 文件的任何更改都必须提交并推送以生效。
 ### 创建存储库
 默认情况下，Gitolite 假设存储库的创建是从上至下进行。例如，有权访问 Git 服务器的项目经理创建了一个项目存储库，并通过 Gitolite 管理仓库添加了开发人员。
 实际上，你可能更愿意向用户授予创建存储库的权限。Gitolite 称这些为“<ruby>野生仓库（通配仓库）<rt>wild repos</rt></ruby>”（我不确定这是关于仓库的形成方式的描述，还是指配置文件所需的通配符）。这是一个例子：
 ```
@managers = alice bob
 repo foo/CREATOR/[a-z]..*
    C   =   @managers
    RW+ =   CREATOR
    RW  =   WRITERS
    R   =   READERS
 ```
 第一行定义了一组用户：该组称为 `@managers`，其中包含用户 `alice` 和 `bob`。下一行设置了通配符允许创建尚不存在的存储库，放在名为 `foo` 的目录下的创建存储库的用户名的子目录中。例如：
 ```
 [alice]$ git clone git@example.com:foo/alice/cool-app.git
 Cloning into cool-app'...
 Initialized empty Git repository in /home/git/repositories/foo/alice/cool-app.git
 warning: You appear to have cloned an empty repository.
 ```
 野生仓库的创建者可以使用一些机制来定义谁可以读取和写入其存储库，但是他们是被限定范围的。在大多数情况下，Gitolite 假定由一组特定的用户来管理项目权限。一种解决方案是使用 Git 挂钩授予所有用户对 `gitolite-admin` 的访问权限，以要求管理者批准将更改合并到 master 分支中。
 ### 了解更多
 Gitolite 具有比此介绍性文章涵盖的更多功能，因此请尝试一下。其[文档][8]非常出色，一旦你通读了它，就可以自定义 Gitolite 服务器，以向用户提供你喜欢的任何级别的控制。Gitolite 是一种维护成本低、简单的系统，你可以安装、设置它，然后基本上就可以将其忘却。
 --------------------------------------------------------------------------------
 via: https://opensource.com/article/19/4/server-administration-git
 作者：[Seth Kenlon][a]
 选题：[lujun9972][b]
 译者：[wxy](https://github.com/wxy)
 校对：[校对者ID](https://github.com/校对者ID)
 本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
 [a]: https://opensource.com/users/seth/users/seth
 [b]: https://github.com/lujun9972
 [1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/server_data_system_admin.png?itok=q6HCfNQ8 (computer servers processing data)
 [2]: https://git-scm.com/
 [3]: http://gitolite.com
 [4]: http://gitea.io
 [5]: Setting%20up%20SSH%20key%20authentication
 [6]: mailto:git@example.com
 [7]: https://opensource.com/article/19/4/file-sharing-git
 [8]: http://gitolite.com/gitolite/quick_install.html
--- a/translated/tech/20200107
+++ b/translated/tech/20200107
@ -0,0 +1,128 @@
 [#]: collector: (lujun9972)
 [#]: translator: (heguangzhi)
 [#]: reviewer: ( )
 [#]: publisher: ( )
 [#]: url: ( )
 [#]: subject: (How piwheels will save Raspberry Pi users time in 2020)
 [#]: via: (https://opensource.com/article/20/1/piwheels)
 [#]: author: (Ben Nuttall https://opensource.com/users/bennuttall)
 piwheels 是如何在2020年节省树莓派用户的时间的
 ======
 通过为树莓派提供预编译的 Python 包，piwheels 项目为用户节省了大量的时间和精力。![rainbow colors on pinwheels in the sun][1]
 piwheels 自动为[PiPi][2]上的所有项目构建 Python wheels( 预编译的 Python包 )，即 Python 包索引，使用树莓派硬件确保其兼容性。这意味着，当树莓派用户想要使用 **pip**，安装一个Python库时，他们会得到一个现成的编译版本，并保证可以在树莓派上良好的工作。这使得树莓派用户更容易进入和开始他们的项目。
 ![Piwheels logo][3]
 当我在2018年10月写[piwheels:为树莓派提供快速 Python 包安装][4]时，piwheels 项目已经进入第一年，并且已经证明了其为树莓派用户节省大量时间和精力。但是这个项目已经进入第二年，它为树莓派提供了预编译的 Python 包走了更长的路。
 ![Raspberry Pi 4][5]
 ### 它是怎么工作的
 [Raspbian][6]，树莓派的主要操作系统，预配置使用 piwheels，所以用户不需要做任何特殊的事情就可以使用piwheels。
 配置文件(在 **/etc/pip.conf**)告诉 pip 使用[piwheels.org][7]作为 _附加索引_，因此 pip 首先查看PyPI，然后查看 piwheels。piwheels 网站位于树莓派 3的 hosts中，该项目建造的所有 wheels 都位于该派上。它每月提供100多万套服务——对于一台35美元的电脑来说还不错！
 网站除了主要服务于树莓派以外，piwheels 项目还对使用其他七个派系统并构建软件包。有人运行 Raspbian Jessie，为 Python 3.4 建造 wheels，有人运行 Raspbian Stretch 为 Python 3.5，有人运行 Raspbian Buster 为 Python 3.7。该项目通常不支持其他 Python 版本。还有一个“合适的服务器”——运行 Postgres 数据库的虚拟机。由于 派3 只有1GB的内存，所以(非常大的)数据库不能在其上很好地运行，所以我们把它移到了虚拟机上。带 4GB 内存的 派4 可能是合适的，所以我们将来可能会用到它。
 派都在“派云”中的 IPv6 网络上——这是一项由总部位于剑桥的托管公司[Mythic Beasts][8]提供的卓越的服务。
 ![Mythic Beasts hosting service][9]
 ### 下载和统计趋势
 每次下载 piwheels 文件时，它都会记录在数据库中。这提供了对什么包最受欢迎以及人们使用什么 Python 版本和操作系统的统计。我们没有太多来自用户代理的信息，但是因为 派1/Zero 的架构显示为 “armv6”，派2/3/4显示为“armv7”，所以我们可以将它们区分开来。
 截至2019年12月中旬，从派风车下载的软件包超过1，400万个，仅2019年就有近900万个。
 自项目开始以来最受欢迎的10个软件包是:
  1. [pycparser][10] (821,060 downloads)
  2. [PyYAML][11] (366,979)
  3. [numpy][12] (354,531)
  4. [cffi][13] (336,982)
  5. [MarkupSafe][14] (318,878)
  6. [future][15] (282,349)
  7. [aiohttp][16] (277,046)
  8. [cryptography][17] (276,167)
  9. [home-assistant-frontend][18] (266,667)
  10. [multidict][19] (256,185)
 请注意，许多纯 Python 包，如[urllib3][20]，都是作为 PyPI 上的 wheels 提供的；因为这些是跨平台兼容的，所以通常不会从 piwheels 下载，因为PyPI优先。
 随着时间的推移，我们也看到了使用哪些 Python 版本的趋势。这里显示了 Raspbian Buster 发布时从3.5版快速升级到了Python 3.7:
 ![Data from piwheels on Python versions used over time][21]
 你可以看到更多的统计趋势在[stats blog posts][22]。
 ### 节省时间
 每个包构建都被记录在数据库中，并且每个下载也被存储。带有构建持续时间的交叉引用下载显示了节省了多少时间。一个例子是 numpy ——最新版本大约需要11分钟来构建。
 迄今为止，piwheels 项目已经为用户节省了总计超过165年的构建时间。按照目前的使用率，piwheels 项目每天节省200多天。
 除了节省构建时间，拥有预编译的 wheels 也意味着人们不必安装各种开发工具来构建包。一些包需要其他apt包来访问共享库。弄清楚你需要哪一个可能会很痛苦，所以我们也让这一步变得容易了。首先，我们找到了这个过程，[在博客上记录了这个过程][23]。然后，我们将这个逻辑添加到构建过程中，这样当构建一个 wheels 时，它的依赖关系会被自动计算并添加到包的项目页面中:
 ![numpy dependencies][24]
 ### 派风车的下一步是什么？
 今年，我们推出了项目页面(例如，[numpy][25)，这是一种非常有用的方式，可以让人们以人类可读的方式查找项目信息。它们还使人们更容易报告问题，例如 piwheels 中缺少一个项目，或者他们下载的包有问题。
 2020年初，我们计划对 piwheels 项目进行一些升级，以启用新的JSON应用编程接口，这样你就可以自动检查哪些版本可用，查找项目的依赖关系，等等。
 下一次 Debian/Raspbian 升级要到2021年年中才会发生，所以在那之前我们不会开始为任何新的 Python 版本 制造 wheels。
 你可以在这个项目的[博客][26]上读到更多关于 piwheels 的信息，我将在2020年初在那里发表一篇2019年的综述。你也可以在推特上关注[@piwheels][27]，在那里你可以看到每日和每月的统计数据以及任何达到的里程碑。
 当然，piwheels 是一个开源项目，你可以在[GitHub][28]上看到整个项目源代码。
 --------------------------------------------------------------------------------
 via: https://opensource.com/article/20/1/piwheels
 作者：[Ben Nuttall][a]
 选题：[lujun9972][b]
 译者：[heguangzhi](https://github.com/heguangzhi)
 校对：[校对者ID](https://github.com/校对者ID)
 本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
 [a]: https://opensource.com/users/bennuttall
 [b]: https://github.com/lujun9972
 [1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/rainbow-pinwheel-piwheel-diversity-inclusion.png?itok=di41Wd3V (rainbow colors on pinwheels in the sun)
 [2]: https://pypi.org/
 [3]: https://opensource.com/sites/default/files/uploads/piwheels.png (Piwheels logo)
 [4]: https://opensource.com/article/18/10/piwheels-python-raspberrypi
 [5]: https://opensource.com/sites/default/files/uploads/raspberry-pi-4_0.jpg (Raspberry Pi 4)
 [6]: https://www.raspberrypi.org/downloads/raspbian/
 [7]: http://piwheels.org
 [8]: https://www.mythic-beasts.com/order/rpi
 [9]: https://opensource.com/sites/default/files/uploads/pi-cloud.png (Mythic Beasts hosting service)
 [10]: https://www.piwheels.org/project/pycparser
 [11]: https://www.piwheels.org/project/PyYAML
 [12]: https://www.piwheels.org/project/numpy
 [13]: https://www.piwheels.org/project/cffi
 [14]: https://www.piwheels.org/project/MarkupSafe
 [15]: https://www.piwheels.org/project/future
 [16]: https://www.piwheels.org/project/aiohttp
 [17]: https://www.piwheels.org/project/cryptography
 [18]: https://www.piwheels.org/project/home-assistant-frontend
 [19]: https://www.piwheels.org/project/multidict
 [20]: https://piwheels.org/project/urllib3/
 [21]: https://opensource.com/sites/default/files/uploads/pyvers2019.png (Data from piwheels on Python versions used over time)
 [22]: https://blog.piwheels.org/piwheels-stats-for-2019/
 [23]: https://blog.piwheels.org/how-to-work-out-the-missing-dependencies-for-a-python-package/
 [24]: https://opensource.com/sites/default/files/uploads/numpy-deps.png (numpy dependencies)
 [25]: https://www.piwheels.org/project/numpy/
 [26]: https://blog.piwheels.org/
 [27]: https://twitter.com/piwheels
 [28]: https://github.com/piwheels/