document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-01-04 22:00:34 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'LCTT/master'

Browse Source
This commit is contained in:
Xingyu.Wang 2018-11-02 16:40:18 +08:00
commit d6eb33ee6b
12 changed files with 1463 additions and 179 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
translated/tech/20181029 4 open source Android email clients.md → published/20181029 4 open source Android email clients.md
View File

@ -1,37 +1,39 @@
四个开源的Android邮件客户端
四个开源的 Android 邮件客户端
======
Email 现在还没有绝迹，而且现在大部分邮件都来自于移动设备。
> Email 现在还没有绝迹，而且现在大部分邮件都来自于移动设备。
![](https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/email_mail_box_envelope_send_blue.jpg?itok=6Epj47H6)
现在一些年轻人正将邮件称之为“老年人的交流方式”，然而事实却是邮件绝对还没有消亡。虽然[协作工具][1]，社交媒体，和短信很常用，但是它们还没做好取代邮件这种必要的商业（和社交）通信工具。
现在一些年轻人正将邮件称之为“老年人的交流方式”，然而事实却是邮件绝对还没有消亡。虽然[协作工具][1]、社交媒体，和短信很常用，但是它们还没做好取代邮件这种必要的商业（和社交）通信工具的准备。
考虑到邮件还没有消失，并且（很多研究表明）人们都是在移动设备上阅读邮件，拥有一个好的移动邮件客户端就变得很关键。如果你是一个想使用开源的邮件客户端的 Android 用户，事情就变得有点棘手了。
我们提供了四个开源的 Andorid 邮件客户端供选择。其中两个可以通过 Andorid 官方应用商店 [Google Play][2] 下载。你也可以在 [Fossdroid][3] 或者 [F-Droid][4] 这些开源 Android 应用库中找到他们。（下方有每个应用的具体下载方式。）
### K-9 Mail
[K-9 Mail][5] 拥有几乎和 Android 一样长的历史——它起源于 Android 1.0 邮件客户端的一个补丁。它支持 IMAP 和 WebDAV、多用户、附件、emojis 和其他经典的邮件客户端功能。它的[用户文档][6]提供了关于安装、启动、安全、阅读和发送邮件等等的帮助。
[K-9 Mail][5] 拥有几乎和 Android 一样长的历史——它起源于 Android 1.0 邮件客户端的一个补丁。它支持 IMAP 和 WebDAV、多用户、附件、emoji 和其它经典的邮件客户端功能。它的[用户文档][6]提供了关于安装、启动、安全、阅读和发送邮件等等的帮助。
K-9 基于 [Apache 2.0][7] 协议开源，[源码][8]可以从 GitHub 上获得. 应用可以从 [Google Play][9]、[Amazon][10] 和 [F-Droid][11] 上下载。
### p≡p
正如它的全称，”Pretty Easy Privacy”说的那样，[p≡p][12] 主要关注于隐私和安全通信。它提供自动的、端到端的邮件和附件加密（但要求你的收件人也要能够加密邮件——否则，p≡p会警告你的邮件将不加密发出）。
正如它的全称，”Pretty Easy Privacy”说的那样，[p≡p][12] 主要关注于隐私和安全通信。它提供自动的、端到端的邮件和附件加密（但要求你的收件人也要能够加密邮件——否则，p≡p 会警告你的邮件将不加密发出）。
你可以从 GitLab 获得[源码][13]（基于 [GPLv3][14] 协议），并且可以从应用的官网上找到相应的[文档][15]。应用可以在 [Fossdroid][16] 上免费下载或者在 [Google Play][17] 上支付一点儿象征性的费用下载。
### InboxPager
[InboxPager][18] 允许你通过 SSL/TLS 协议收发邮件信息，这也表明如果你的邮件提供商（比如 Gmail ）没有默认开启这个功能的话，你可能要做一些设置。（幸运的是， InboxPager 提供了 Gmail的[设置教程][19]。）它同时也支持通过 OpenKeychain 应用进行 OpenPGP 机密。
[InboxPager][18] 允许你通过 SSL/TLS 协议收发邮件信息，这也表明如果你的邮件提供商（比如 Gmail ）没有默认开启这个功能的话，你可能要做一些设置。（幸运的是， InboxPager 提供了 Gmail 的[设置教程][19]。）它同时也支持通过 OpenKeychain 应用进行 OpenPGP 加密。
InboxPager 基于 [GPLv3][20] 协议，其源码可从 GitHub 获得，并且应用可以从 [F-Droid][21] 下载。
### FairEmail
[FairEmail][22] 是一个极简的邮件客户端，它的功能集中于读写信息，没有任何多余的可能拖慢客户端的功能。它支持多个帐号和用户，消息线程，加密等等。
[FairEmail][22] 是一个极简的邮件客户端，它的功能集中于读写信息，没有任何多余的可能拖慢客户端的功能。它支持多个帐号和用户、消息线索、加密等等。
它基于 [GPLv3][23] 协议开源，[源码][24]可以从GitHub上获得。你可以在 [Fossdroid][25] 上下载 FairEamil； 对 Google Play 版本感兴趣的人可以从 [testing the software][26] 获得应用。
它基于 [GPLv3][23] 协议开源，[源码][24]可以从 GitHub 上获得。你可以在 [Fossdroid][25] 上下载 FairEamil；对 Google Play 版本感兴趣的人可以从 [testing the software][26] 获得应用。
肯定还有更多的开源 Android 客户端（或者上述软件的加强版本）——活跃的开发者们可以关注一下。如果你知道还有哪些优秀的应用，可以在评论里和我们分享。
@ -42,7 +44,7 @@ via: https://opensource.com/article/18/10/open-source-android-email-clients
作者：[Opensource.com][a]
选题：[lujun9972][b]
译者：[zianglei][c]
校对：[校对者ID](https://github.com/校对者ID)
校对：[wxy](https://github.com/wxy)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出

275
sources/tech/20180612 Systemd Services- Reacting to Change.md Normal file
View File

@ -0,0 +1,275 @@
Systemd Services: Reacting to Change
======
![](https://www.linux.com/sites/lcom/files/styles/rendered_file/public/webcam.png?itok=zzYUs5VK)
[I have one of these Compute Sticks][1] (Figure 1) and use it as an all-purpose server. It is inconspicuous and silent and, as it is built around an x86 architecture, I don't have problems getting it to work with drivers for my printer, and that’s what it does most days: it interfaces with the shared printer and scanner in my living room.
![ComputeStick][3]
An Intel ComputeStick. Euro coin for size.
[Used with permission][4]
Most of the time it is idle, especially when we are out, so I thought it would be good idea to use it as a surveillance system. The device doesn't come with its own camera, and it wouldn't need to be spying all the time. I also didn't want to have to start the image capturing by hand because this would mean having to log into the Stick using SSH and fire up the process by writing commands in the shell before rushing out the door.
So I thought that the thing to do would be to grab a USB webcam and have the surveillance system fire up automatically just by plugging it in. Bonus points if the surveillance system fired up also after the Stick rebooted, and it found that the camera was connected.
In prior installments, we saw that [systemd services can be started or stopped by hand][5] or [when certain conditions are met][6]. Those conditions are not limited to when the OS reaches a certain state in the boot up or powerdown sequence but can also be when you plug in new hardware or when things change in the filesystem. You do that by combining a Udev rule with a systemd service.
### Hotplugging with Udev
Udev rules live in the _/etc/udev/rules_ directory and are usually a single line containing _conditions_ and _assignments_ that lead to an _action_.
That was a bit cryptic. Let's try again:
Typically, in a Udev rule, you tell systemd what to look for when a device is connected. For example, you may want to check if the make and model of a device you just plugged in correspond to the make and model of the device you are telling Udev to wait for. Those are the _conditions_ mentioned earlier.
Then you may want to change some stuff so you can use the device easily later. An example of that would be to change the read and write permissions to a device: if you plug in a USB printer, you're going to want users to be able to read information from the printer (the user's printing app would want to know the model, make, and whether it is ready to receive print jobs or not) and write to it, that is, send stuff to print. Changing the read and write permissions for a device is done using one of the _assignments_ you read about earlier.
Finally, you will probably want the system to do something when the conditions mentioned above are met, like start a backup application to copy important files when a certain external hard disk drive is plugged in. That is an example of an _action_ mentioned above.
With that in mind, ponder this:
```
ACTION=="add", SUBSYSTEM=="video4linux", ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="e207",
SYMLINK+="mywebcam", TAG+="systemd", MODE="0666", ENV{SYSTEMD_WANTS}="webcam.service"
```
The first part of the rule,
```
ACTION=="add", SUBSYSTEM=="video4linux", ATTRS{idVendor}=="03f0",
ATTRS{idProduct}=="e207" [etc... ]
```
shows the conditions that the device has to meet before doing any of the other stuff you want the system to do. The device has to be added (`ACTION=="add"`) to the machine, it has to be integrated into the `video4linux` subsystem. To make sure the rule is applied only when the correct device is plugged in, you have to make sure Udev correctly identifies the manufacturer (`ATTRS{idVendor}=="03f0"`) and a model (`ATTRS{idProduct}=="e207"`) of the device.
In this case, we're talking about this device (Figure 2):
![webcam][8]
The HP webcam used in this experiment.
[Used with permission][4]
Notice how you use `==` to indicate that these are a logical operation. You would read the above snippet of the rule like this:
```
if the device is added and the device controlled by the video4linux subsystem
and the manufacturer of the device is 03f0 and the model is e207, then...
```
But where do you get all this information? Where do you find the action that triggers the event, the manufacturer, model, and so on? You will probably have to use several sources. The `IdVendor` and `idProduct` you can get by plugging the webcam into your machine and running `lsusb`:
```
lsusb
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 003: ID 03f0:e207 Hewlett-Packard
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 04f2:b1bb Chicony Electronics Co., Ltd
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
```
The webcam I’m using is made by HP, and you can only see one HP device in the list above. The `ID` gives you the manufacturer and the model numbers separated by a colon (`:`). If you have more than one device by the same manufacturer and not sure which is which, unplug the webcam, run `lsusb` again and check what's missing.
OR...
Unplug the webcam, wait a few seconds, run the command `udevadmin monitor --environment` and then plug the webcam back in again. When you do that with the HP webcam, you get:
```
udevadmin monitor --environment
UDEV [35776.495221] add /devices/pci0000:00/0000:00:1c.3/0000:04:00.0
  /usb3/3-1/3-1:1.0/input/input21/event11 (input)
.MM_USBIFNUM=00
ACTION=add
BACKSPACE=guess
DEVLINKS=/dev/input/by-path/pci-0000:04:00.0-usb-0:1:1.0-event
  /dev/input/by-id/usb-Hewlett_Packard_HP_Webcam_HD_2300-event-if00
DEVNAME=/dev/input/event11
DEVPATH=/devices/pci0000:00/0000:00:1c.3/0000:04:00.0/
  usb3/3-1/3-1:1.0/input/input21/event11
ID_BUS=usb
ID_INPUT=1
ID_INPUT_KEY=1
ID_MODEL=HP_Webcam_HD_2300
ID_MODEL_ENC=HP\x20Webcam\x20HD\x202300
ID_MODEL_ID=e207
ID_PATH=pci-0000:04:00.0-usb-0:1:1.0
ID_PATH_TAG=pci-0000_04_00_0-usb-0_1_1_0
ID_REVISION=1020
ID_SERIAL=Hewlett_Packard_HP_Webcam_HD_2300
ID_TYPE=video
ID_USB_DRIVER=uvcvideo
ID_USB_INTERFACES=:0e0100:0e0200:010100:010200:030000:
ID_USB_INTERFACE_NUM=00
ID_VENDOR=Hewlett_Packard
ID_VENDOR_ENC=Hewlett\x20Packard
ID_VENDOR_ID=03f0
LIBINPUT_DEVICE_GROUP=3/3f0/e207:usb-0000:04:00.0-1/button
MAJOR=13
MINOR=75
SEQNUM=3162
SUBSYSTEM=input
USEC_INITIALIZED=35776495065
XKBLAYOUT=es
XKBMODEL=pc105
XKBOPTIONS=
XKBVARIANT=
```
That may look like a lot to process, but, check this out: the `ACTION` field early in the list tells you what event just happened, i.e., that a device got added to the system. You can also see the name of the device spelled out on several of the lines, so you can be pretty sure that it is the device you are looking for. The output also shows the manufacturer's ID number (`ID_VENDOR_ID=03f0`) and the model number (`ID_VENDOR_ID=03f0`).
This gives you three of the four values the condition part of the rule needs. You may be tempted to think that it a gives you the fourth, too, because there is also a line that says:
```
SUBSYSTEM=input
```
Be careful! Although it is true that a USB webcam is a device that provides input (as does a keyboard and a mouse), it is also belongs to the _usb_ subsystem, and several others. This means that your webcam gets added to several subsystems and looks like several devices. If you pick the wrong subsystem, your rule may not work as you want it to, or, indeed, at all.
So, the third thing you have to check is all the subsystems the webcam has got added to and pick the correct one. To do that, unplug your webcam again and run:
```
ls /dev/video*
```
This will show you all the video devices connected to the machine. If you are using a laptop, most come with a built-in webcam and it will probably show up as `/dev/video0`. Plug your webcam back in and run `ls /dev/video*` again.
Now you should see one more video device (probably `/dev/video1`).
Now you can find out all the subsystems it belongs to by running `udevadm info -a /dev/video1`:
```
udevadm info -a /dev/video1
Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/devices/pci0000:00/0000:00:1c.3/0000:04:00.0
  /usb3/3-1/3-1:1.0/video4linux/video1':
KERNEL=="video1"
SUBSYSTEM=="video4linux"
DRIVER==""
ATTR{dev_debug}=="0"
ATTR{index}=="0"
ATTR{name}=="HP Webcam HD 2300: HP Webcam HD"
[etc...]
```
The output goes on for quite a while, but what you're interested is right at the beginning: `SUBSYSTEM=="video4linux"`. This is a line you can literally copy and paste right into your rule. The rest of the output (not shown for brevity) gives you a couple more nuggets, like the manufacturer and mode IDs, again in a format you can copy and paste into your rule.
Now you have a way of identifying the device and what event should trigger the action univocally, it is time to tinker with the device.
The next section in the rule, `SYMLINK+="mywebcam", TAG+="systemd", MODE="0666"` tells Udev to do three things: First, you want to create symbolic link from the device to (e.g. _/dev/video1_ ) to _/dev/mywebcam_. This is because you cannot predict what the system is going to call the device by default. When you have an in-built webcam and you hotplug a new one, the in-built webcam will usually be _/dev/video0_ while the external one will become _/dev/video1_. However, if you boot your computer with the external USB webcam plugged in, that could be reversed and the internal webcam can become _/dev/video1_ and the external one _/dev/video0_. What this is telling you is that, although your image-capturing script (which you will see later on) always needs to point to the external webcam device, you can't rely on it being _/dev/video0_ or _/dev/video1_. To solve this problem, you tell Udev to create a symbolic link which will never change in the moment the device is added to the _video4linux_ subsystem and you will make your script point to that.
The second thing you do is add `"systemd"` to the list of Udev tags associated with this rule. This tells Udev that the action that the rule will trigger will be managed by systemd, that is, it will be some sort of systemd service.
Notice how in both cases you use `+=` operator. This adds the value to a list, which means you can add more than one value to `SYMLINK` and `TAG`.
The `MODE` values, on the other hand, can only contain one value (hence you use the simple `=` assignment operator). What `MODE` does is tell Udev who can read from or write to the device. If you are familiar with `chmod` (and, if you are reading this, you should be), you will also be familiar of [how you can express permissions using numbers][9]. That is what this is: `0666` means " _give read and write privileges to the device to everybody_ ".
At last, `ENV{SYSTEMD_WANTS}="webcam.service"` tells Udev what systemd service to run.
Save this rule into file called _90-webcam.rules_ (or something like that) in _/etc/udev/rules.d_ and you can load it either by rebooting your machine, or by running:
```
sudo udevadm control --reload-rules && udevadm trigger
```
## Service at Last
The service the Udev rule triggers is ridiculously simple:
```
# webcam.service
[Service]
Type=simple
ExecStart=/home/[user name]/bin/checkimage.sh
```
Basically, it just runs the _checkimage.sh_ script stored in your personal _bin/_ and pushes it the background. [This is something you saw how to do in prior installments][5]. It may seem something little, but just because it is called by a Udev rule, you have just created a special kind of systemd unit called a _device_ unit. Congratulations.
As for the _checkimage.sh_ script _webcam.service_ calls, there are several ways of grabbing an image from a webcam and comparing it to a prior one to check for changes (which is what _checkimage.sh_ does), but this is how I did it:
```
#!/bin/bash
# This is the checkimage.sh script
mplayer -vo png -frames 1 tv:// -tv driver=v4l2:width=640:height=480:device=
  /dev/mywebcam &>/dev/null
mv 00000001.png /home/[user name]/monitor/monitor.png
while true
do
mplayer -vo png -frames 1 tv:// -tv driver=v4l2:width=640:height=480:device=/dev/mywebcam &>/dev/null
mv 00000001.png /home/[user name]/monitor/temp.png
imagediff=`compare -metric mae /home/[user name]/monitor/monitor.png /home/[user name]
  /monitor/temp.png /home/[user name]/monitor/diff.png 2>&1 > /dev/null | cut -f 1 -d " "`
if [ `echo "$imagediff > 700.0" | bc` -eq 1 ]
then
mv /home/[user name]/monitor/temp.png /home/[user name]/monitor/monitor.png
fi
sleep 0.5
done
```
Start by using [MPlayer][10] to grab a frame ( _00000001.png_ ) from the webcam. Notice how we point `mplayer` to the `mywebcam` symbolic link we created in our Udev rule, instead of to `video0` or `video1`. Then you transfer the image to the _monitor/_ directory in your home directory. Then run an infinite loop that does the same thing again and again, but also uses [Image Magick's _compare_ tool][11] to see if there any differences between the last image captured and the one that is already in the _monitor/_ directory.
If the images are different, it means something has moved within the webcam's frame. The script overwrites the original image with the new image and continues comparing waiting for some more movement.
### Plugged
With all the bits and pieces in place, when you plug your webcam in, your Udev rule will be triggered and will start the _webcam.service_. The _webcam.service_ will execute _checkimage.sh_ in the background, and _checkimage.sh_ will start taking pictures every half a second. You will know because your webcam's LED will start flashing indicating every time it takes a snap.
As always, if something goes wrong, run
```
systemctl status webcam.service
```
to check what your service and script are up to.
### Coming up
You may be wondering: Why overwrite the original image? Surely you would want to see what's going on if the system detects any movement, right? You would be right, but as you will see in the next installment, leaving things as they are and processing the images using yet another type of systemd unit makes things nice, clean and easy.
Just wait and see.
Learn more about Linux through the free ["Introduction to Linux" ][12]course from The Linux Foundation and edX.
--------------------------------------------------------------------------------
via: https://www.linux.com/blog/intro-to-linux/2018/6/systemd-services-reacting-change
作者：[Paul Brown][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://www.linux.com/users/bro66
[b]: https://github.com/lujun9972
[1]: https://www.intel.com/content/www/us/en/products/boards-kits/compute-stick/stk1a32sc.html
[2]: https://www.linux.com/files/images/fig01png
[3]: https://www.linux.com/sites/lcom/files/styles/floated_images/public/fig01.png?itok=cfEHN5f1 (ComputeStick)
[4]: https://www.linux.com/licenses/category/used-permission
[5]: https://www.linux.com/blog/learn/intro-to-linux/2018/5/writing-systemd-services-fun-and-profit
[6]: https://www.linux.com/blog/learn/2018/5/systemd-services-beyond-starting-and-stopping
[7]: https://www.linux.com/files/images/fig02png
[8]: https://www.linux.com/sites/lcom/files/styles/floated_images/public/fig02.png?itok=esFv4BdM (webcam)
[9]: https://chmod-calculator.com/
[10]: https://mplayerhq.hu/design7/news.html
[11]: https://www.imagemagick.org/script/compare.php
[12]: https://training.linuxfoundation.org/linux-courses/system-administration-training/introduction-to-linux

152
sources/tech/20180619 Systemd Services- Monitoring Files and Directories.md Normal file
View File

@ -0,0 +1,152 @@
Systemd Services: Monitoring Files and Directories
======
![](https://www.linux.com/sites/lcom/files/styles/rendered_file/public/systemd-filesystem.png?itok=iGjxwoJR)
So far in this systemd multi-part tutorial, we’ve covered [how to start and stop a service by hand][1], [how to start a service when booting your OS and have it stop on power down][2], and [how to boot a service when a certain device is detected][3]. This installment does something different yet again and covers how to create a unit that starts a service when something changes in the filesystem. For the practical example, you'll see how you can use one of these units to extend the [surveillance system we talked about last time][4].
### Where we left off
[Last time we saw how the surveillance system took pictures, but it did nothing with them][3]. In fact, it even overwrote the last picture it took when it detected movement so as not to fill the storage of the device.
Does that mean the system is useless? Not by a long shot. Because, you see, systemd offers yet another type of units, _paths_ , that can help you out. _Path_ units allow you to trigger a service when an event happens in the filesystem, say, when a file gets deleted or a directory accessed. And, overwriting an image is exactly the kind of event we are talking about here.
### Anatomy of a Path Unit
A systemd path unit takes the extension _.path_ , and it monitors a file or directory. A _.path_ unit calls another unit (usually a _.service_ unit with the same name) when something happens to the monitored file or directory. For example, if you have a _picchanged.path_ unit to monitor the snapshot from your webcam, you will also have a _picchanged.service_ that will execute a script when the snapshot is overwritten.
Path units contain a new section, `[Path]`, with few more directives. First, you have the what-to-watch-for directives:
* **`PathExists=`** monitors whether the file or directory exists. If it does, the associated unit gets triggered. `PathExistsGlob=` works in a similar fashion, but lets you use globbing, like when you use `ls *.jpg` to search for all the JPEG images in a directory. This lets you check, for example, whether a file with a certain extension exists.
* **`PathChanged=`** watches a file or directory and activates the configured unit whenever it changes. It is not activated on every write to the watched file but only when a monitored file open for for writing is changed and then closed. The associated unit is executed when the file is closed.
* **`PathModified=`** , on the other hand, does activate the unit when anything is changed in the file you are monitoring, even before you close the file.
* **`DirectoryNotEmpty=`** does what it says on the box, that is, it activates the associated unit if the monitored directory contains files or subdirectories.
Then, we have `Unit=` that tells the _.path_ which _.service_ unit to activate, in case you want to give it a different name to that of your _.path_ unit; `MakeDirectory=` can be `true` or `false` (or `0` or `1`, or `yes` or `no`) and creates the directory you want to monitor before monitoring starts. Obviously, using `MakeDirectory=` in combination with `PathExists=` does not make sense. However, `MakeDirectory=` can be used in combination with `DirectoryMode=`, which you use to set the the mode (permissions) of the new directory. If you don't use `DirectoryMode=`, the default permissions for the new directory are `0755`.
### Building _picchanged.path_
All these directives are very useful, but you will be just looking for changes made to one single file, so your _.path_ unit is very simple:
```
#picchanged.path
[Unit]
Wants= webcam.service
[Path]
PathChanged= /home/[user name]/monitor/monitor.jpg
```
In the `Unit=` section the line that says
```
Wants= webcam.service
```
The `Wants=` directive is the preferred way of starting up a unit the current unit needs to work properly. [`webcam.service` is the name you gave the surveillance service that you saw in the previous article][3] and is the service that actually controls the webcam and makes it take a snap every half second. This means it’s _picchanged.path_ that is going to start up _webcam.service_ now, and not the [Udev rule you saw in the prior article][3]. You will use the Udev rule to start _picchanged.path_ instead.
To summarize: the Udev rule pulls in your new _picchanged.path_ unit, which, in turn pulls in the _webcam.service_ as a requirement for everything to work perfectly.
The "thing" that _picchanged.path_ monitors is the _monitor.jpg_ file in the _monitor/_ directory in your home directory. As you saw last time, _webcam.service_ called a script, _checkimage.sh_ , took a picture at the beginning of its execution and stored it in _monitor/temp.jpg_. _checkimage.sh_ then took another pic, _temp.jpg_ , and compared it with _monitor.jpg_. If it found significant differences (like when somebody walks into frame) the script overwrote _monitor.jpg_ with the _temp.jpg_. That is when _picchanged.path_ fires.
As you haven't included a `Unit=` directive in your _.path_ , the unit systemd expects a matching _picchanged.service_ unit which it will trigger when _/home/[ _user name_ ]/monitor/monitor.jpg_ gets modified:
```
#picchanged.service
[Service]
Type= simple
ExecStart= /home/[user name]/bin/picmonitor.sh
```
For the time being, let’s make _picmonitor.sh_ save a time-stamped copy of _monitor.jpg_ every time changes get detected:
```
#!/bin/bash
# This is the pcmonitor.sh script
cp /home/[user name]/monitor/monitor.jpg /home/[user name]/monitor/"`date`.jpg"
```
### Udev Changes
You have to change the custom Udev rule you wrote in [the previous installment][3] so everything works. Edit _/etc/udev/rules.d/01-webcam.rules_ so instead of looking like this:
```
ACTION=="add", SUBSYSTEM=="video4linux", ATTRS{idVendor}=="03f0",
  ATTRS{idProduct}=="e207", SYMLINK+="mywebcam", TAG+="systemd",
  MODE="0666", ENV{SYSTEMD_WANTS}="webcam.service"
```
It looks like this:
```
ACTION=="add", SUBSYSTEM=="video4linux", ATTRS{idVendor}=="03f0",
  ATTRS{idProduct}=="e207", SYMLINK+="mywebcam", TAG+="systemd",
  MODE="0666", ENV{SYSTEMD_WANTS}="picchanged.path"
```
The new rule, instead of calling _webcam.service_ , now calls _picchanged.path_ when your webcam gets detected. (Note that you will have to change the `idVendor` and `IdProduct` to those of your own webcam -- you saw how to find these out previously).
For the record, I also changed _checkimage.sh_ from using PNG to JPEG images. I did this because I found some dependency problems with PNG images when working with _mplayer_ on some versions of Debian. _checkimage.sh_ now looks like this:
```
#!/bin/bash
mplayer -vo jpeg -frames 1 tv:// -tv driver=v4l2:width=640:height=480:device=
  /dev/mywebcam &>/dev/null
mv 00000001.jpg /home/paul/monitor/monitor.jpg
while true
do
mplayer -vo jpeg -frames 1 tv:// -tv driver=v4l2:width=640:height=480:device=
  /dev/mywebcam &>/dev/null
mv 00000001.jpg /home/paul/monitor/temp.jpg
imagediff=`compare -metric mae /home/paul/monitor/monitor.jpg
  /home/paul/monitor/temp.jpg /home/paul/monitor/diff.png 2>&1 >
  /dev/null | cut -f 1 -d " "`
if [ `echo "$imagediff > 700.0" | bc` -eq 1 ]
then
mv /home/paul/monitor/temp.jpg /home/paul/monitor/monitor.jpg
fi
sleep 0.5
done
```
### Firing up
This is a multi-unit service that, when all its bits and pieces are in place, you don't have to worry much about: you plug in the designated webcam (or boot the machine with the webcam already connected), _picchanged.path_ gets started thanks to the Udev rule and takes over, bringing up the _webcam.service_ and starting to check on the snaps. There is nothing else you need to do.
### Conclusion
Having the process split into two doesn't only help explain how path units work, but it’s also very useful for debugging. One service does not "touch" the other in any way, which means that you could, for example, improve the "motion detection" part, and it would be very easy to roll back if things didn't work as expected.
Admittedly, the example is a bit goofy, as there are definitely [better ways of monitoring movement using a webcam][5]. But remember: the main aim of these articles is to help you learn how systemd units work within a context.
Next time, we'll finish up with systemd units by looking at some of the other types of units available and show how to improve your home-monitoring system further by setting up service that sends images to another machine.
Learn more about Linux through the free ["Introduction to Linux" ][6]course from The Linux Foundation and edX.
--------------------------------------------------------------------------------
via: https://www.linux.com/blog/learn/intro-to-linux/2018/6/systemd-services-monitoring-files-and-directories
作者：[Paul Brown][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://www.linux.com/users/bro66
[b]: https://github.com/lujun9972
[1]: https://www.linux.com/blog/learn/intro-to-linux/2018/5/writing-systemd-services-fun-and-profit
[2]: https://www.linux.com/blog/learn/2018/5/systemd-services-beyond-starting-and-stopping
[3]: https://www.linux.com/blog/intro-to-linux/2018/6/systemd-services-reacting-change
[4]: https://www.linux.com/blog/learn/intro-to-linux/2018/6/systemd-services-monitoring-files-and-directories
[5]: https://www.linux.com/learn/how-operate-linux-spycams-motion
[6]: https://training.linuxfoundation.org/linux-courses/system-administration-training/introduction-to-linux

170
sources/tech/20180810 How To Quickly Serve Files And Folders Over HTTP In Linux.md
View File

@ -1,170 +0,0 @@
translating---geekpi
How To Quickly Serve Files And Folders Over HTTP In Linux
======
![](https://www.ostechnix.com/wp-content/uploads/2018/08/http-720x340.png)
Today, I came across a whole bunch of methods to serve a single file or entire directory with other systems in your local area network via a web browser. I tested all of them in my Ubuntu test machine, and everything worked just fine as described below. If you ever wondered how to easily and quickly serve files and folders over HTTP in Unix-like operating systems, one of the following methods will definitely help.
### Serve Files And Folders Over HTTP In Linux
**Disclaimer:** All the methods given here are meant to be used within a secure local area network. Since these methods doesn’t have any security mechanism, it is **not recommended to use them in production**. You have been warned!
#### Method 1 – Using simpleHTTPserver (Python)
We already have written a brief guide to setup a simple http server to share files and directories instantly in the following link. If you have a system with Python installed, this method is quite handy.
#### Method 2 – Using Quickserve (Python)
This method is specifically for Arch Linux and its variants. Check the following link for more details.
#### Method 3 – Using Ruby**
In this method, we use Ruby to serve files and folders over HTTP in Unix-like systems. Install Ruby and Rails as described in the following link.
Once Ruby installed, go to the directory, for example ostechnix, that you want to share over the network:
```
$ cd ostechnix
```
And, run the following command:
```
$ ruby -run -ehttpd . -p8000
[2018-08-10 16:02:55] INFO WEBrick 1.4.2
[2018-08-10 16:02:55] INFO ruby 2.5.1 (2018-03-29) [x86_64-linux]
[2018-08-10 16:02:55] INFO WEBrick::HTTPServer#start: pid=5859 port=8000
```
Make sure the port 8000 is opened in your router or firewall . If the port has already been used by some other services use different port.
You can now access the contents of this folder from any remote system using URL – **http:// <IP-address>:8000/**.
![](https://www.ostechnix.com/wp-content/uploads/2018/08/ruby-http-server.png)
To stop sharing press **CTRL+C**.
#### Method 4 – Using Http-server (NodeJS)
[**Http-server**][1] is a simple, production ready command line http-server written in NodeJS. It requires zero configuration and can be used to instantly share files and directories via web browser.
Install NodeJS as described below.
Once NodeJS installed, run the following command to install http-server.
```
$ npm install -g http-server
```
Now, go to any directory and share its contents over HTTP as shown below.
```
$ cd ostechnix
$ http-server -p 8000
Starting up http-server, serving ./
Available on:
http://127.0.0.1:8000
http://192.168.225.24:8000
http://192.168.225.20:8000
Hit CTRL-C to stop the server
```
Now, you can access the contents of this directory from local or remote systems in the network using URL – **http:// <ip-address>:8000**.
![](http://www.ostechnix.com/wp-content/uploads/2018/08/nodejs-http-server.png)
To stop sharing, press **CTRL+C**.
#### Method 5 – Using Miniserve (Rust)
[**Miniserve**][2] is yet another command line utility that allows you to quickly serve files over HTTP. It is very fast, easy-to-use, and cross-platform utility written in **Rust** programming language. Unlike the above utilities/methods, it provides authentication support, so you can setup username and password to the shares.
Install Rust in your Linux system as described in the following link.
After installing Rust, run the following command to install miniserve:
```
$ cargo install miniserve
```
Alternatively, you can download the binaries from [**the releases page**][3] and make it executable.
```
$ chmod +x miniserve-linux
```
And, then you can run it using command (assuming miniserve binary file is downloaded in the current working directory):
```
$ ./miniserve-linux <path-to-share>
```
**Usage**
To serve a directory:
```
$ miniserve <path-to-directory>
```
**Example:**
```
$ miniserve /home/sk/ostechnix/
miniserve v0.2.0
Serving path /home/sk/ostechnix at http://[::]:8080, http://localhost:8080
Quit by pressing CTRL-C
```
Now, you can access the share from local system itself using URL – **<http://localhost:8080>** and/or from remote system with URL – **http:// <ip-address>:8080**.
To serve a single file:
```
$ miniserve <path-to-file>
```
**Example:**
```
$ miniserve ostechnix/file.txt
```
Serve file/folder with username and password:
```
$ miniserve --auth joe:123 <path-to-share>
```
Bind to multiple interfaces:
```
$ miniserve -i 192.168.225.1 -i 10.10.0.1 -i ::1 -- <path-to-share>
```
As you can see, I have given only 5 methods. But, there are few more methods given in the link attached at the end of this guide. Go and test them as well. Also, bookmark and revisit it from time to time to check if there are any new additions to the list in future.
And, that’s all for now. Hope this was useful. More good stuffs to come. Stay tuned!
Cheers!
--------------------------------------------------------------------------------
via: https://www.ostechnix.com/how-to-quickly-serve-files-and-folders-over-http-in-linux/
作者：[SK][a]
选题：[lujun9972](https://github.com/lujun9972)
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://www.ostechnix.com/author/sk/
[1]:https://www.npmjs.com/package/http-server
[2]:https://github.com/svenstaro/miniserve
[3]:https://github.com/svenstaro/miniserve/releases

2
sources/tech/20180914 Convert files at the command line with Pandoc.md
View File

@ -1,3 +1,5 @@
Translating by jlztan
Convert files at the command line with Pandoc
======

2
sources/tech/20181004 4 Must-Have Tools for Monitoring Linux.md
View File

@ -1,3 +1,5 @@
### translating by way-ww
4 Must-Have Tools for Monitoring Linux
======

1
sources/tech/20181017 Chrony - An Alternative NTP Client And Server For Unix-like Systems.md
View File

@ -1,3 +1,4 @@
zianglei translating
Chrony – An Alternative NTP Client And Server For Unix-like Systems
======

368
sources/tech/20181030 How Do We Find Out The Installed Packages Came From Which Repository.md Normal file
View File

@ -0,0 +1,368 @@
How Do We Find Out The Installed Packages Came From Which Repository?
======
Sometimes you might want to know the installed packages came from which repository. This will helps you to troubleshoot when you are facing the package conflict issue.
Because [third party vendor repositories][1] are holding the latest version of package and sometime it will causes the issue when you are trying to install any packages due to incompatibility.
Everything is possible in Linux because you can able to install a packages on your system even though when the package is not available on your distribution.
Also, you can able to install a package with latest version when your distribution don’t have it. How?
That’s why third party repositories are came in the picture. They are allowing users to install all the available packages from their repositories.
Almost all the distributions are allowing third party repositories. Some of the distribution officially suggesting few of third party repositories which are not replacing the base packages badly like CentOS officially suggesting us to install [EPEL repository][2].
[List of Major repositories][1] and it’s details are below.
* **`CentOS:`** [EPEL][2], [ELRepo][3], etc is [CentOS Community Approved Repositories][4].
* **`Fedora:`** [RPMfusion repo][5] is commonly used by most of the [Fedora][6] users.
* **`ArchLinux:`** ArchLinux community repository contains packages that have been adopted by Trusted Users from the Arch User Repository.
* **`openSUSE:`** [Packman repo][7] offers various additional packages for openSUSE, especially but not limited to multimedia related applications and libraries that are on the openSUSE Build Service application blacklist. It’s the largest external repository of openSUSE packages.
* **`Ubuntu:`** Personal Package Archives (PPAs) are a kind of repository. Developers create them in order to distribute their software. You can find this information on the PPA’s Launchpad page. Also, you can enable Cananical partners repositories.
### What Is Repository?
A software repository is a central place which stores the software packages for the particular application.
All the Linux distributions are maintaining their own repositories and they allow users to retrieve and install packages on their machine.
Each vendor offered a unique package management tool to manage their repositories such as search, install, update, upgrade, remove, etc.
Most of the Linux distributions comes as freeware except RHEL and SUSE. To access their repositories you need to buy a subscriptions.
### Why do we need to enable third party repositories?
In Linux, installing a package from source is not advisable as this might cause so many issues while upgrading the package or system that’s why we are advised to install a package from repo instead of source.
### How Do We Find Out The Installed Packages Came From Which Repository on RHEL/CentOS Systems?
This can be done in multiple ways. Here we will be giving you all the possible options and you can choose which one is best for you.
### Method-1: Using Yum Command
RHEL & CentOS systems are using RPM packages hence we can use the [Yum Package Manager][8] to get this information.
YUM stands for Yellowdog Updater, Modified is an open-source command-line front-end package-management utility for RPM based systems such as Red Hat Enterprise Linux (RHEL) and CentOS.
Yum is the primary tool for getting, installing, deleting, querying, and managing RPM packages from distribution repositories, as well as other third-party repositories.
```
# yum info apachetop
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* epel: epel.mirror.constant.com
Installed Packages
Name : apachetop
Arch : x86_64
Version : 0.15.6
Release : 1.el7
Size : 65 k
Repo : installed
From repo : epel
Summary : A top-like display of Apache logs
URL : https://github.com/tessus/apachetop
License : BSD
Description : ApacheTop watches a logfile generated by Apache (in standard common or
: combined logformat, although it doesn't (yet) make use of any of the extra
: fields in combined) and generates human-parsable output in realtime.
```
The **`apachetop`** package is coming from **`epel repo`**.
### Method-2: Using Yumdb Command
Yumdb info provides information similar to yum info but additionally it provides package checksum data, type, user info (who installed the package). Since yum 3.2.26 yum has started storing additional information outside of the rpmdatabase (where user indicates it was installed by the user, and dep means it was brought in as a dependency).
```
# yumdb info lighttpd
Loaded plugins: fastestmirror
lighttpd-1.4.50-1.el7.x86_64
checksum_data = a24d18102ed40148cfcc965310a516050ed437d728eeeefb23709486783a4d37
checksum_type = sha256
command_line = --enablerepo=epel install lighttpd apachetop aria2 atop axel
from_repo = epel
from_repo_revision = 1540756729
from_repo_timestamp = 1540757483
installed_by = 0
origin_url = https://epel.mirror.constant.com/7/x86_64/Packages/l/lighttpd-1.4.50-1.el7.x86_64.rpm
reason = user
releasever = 7
var_contentdir = centos
var_infra = stock
var_uuid = ce328b07-9c0a-4765-b2ad-59d96a257dc8
```
The **`lighttpd`** package is coming from **`epel repo`**.
### Method-3: Using RPM Command
[RPM command][9] stands for Red Hat Package Manager is a powerful, command line Package Management utility for Red Hat based system such as (RHEL, CentOS, Fedora, openSUSE & Mageia) distributions.
The utility allow you to install, upgrade, remove, query & verify the software on your Linux system/server. RPM files comes with .rpm extension. RPM package built with required libraries and dependency which will not conflicts other packages were installed on your system.
```
# rpm -qi apachetop
Name : apachetop
Version : 0.15.6
Release : 1.el7
Architecture: x86_64
Install Date: Mon 29 Oct 2018 06:47:49 AM EDT
Group : Applications/Internet
Size : 67020
License : BSD
Signature : RSA/SHA256, Mon 22 Jun 2015 09:30:26 AM EDT, Key ID 6a2faea2352c64e5
Source RPM : apachetop-0.15.6-1.el7.src.rpm
Build Date : Sat 20 Jun 2015 09:02:37 PM EDT
Build Host : buildvm-22.phx2.fedoraproject.org
Relocations : (not relocatable)
Packager : Fedora Project
Vendor : Fedora Project
URL : https://github.com/tessus/apachetop
Summary : A top-like display of Apache logs
Description :
ApacheTop watches a logfile generated by Apache (in standard common or
combined logformat, although it doesn't (yet) make use of any of the extra
fields in combined) and generates human-parsable output in realtime.
```
The **`apachetop`** package is coming from **`epel repo`**.
### Method-4: Using Repoquery Command
repoquery is a program for querying information from YUM repositories similarly to rpm queries.
```
# repoquery -i httpd
Name : httpd
Version : 2.4.6
Release : 80.el7.centos.1
Architecture: x86_64
Size : 9817285
Packager : CentOS BuildSystem
Group : System Environment/Daemons
URL : http://httpd.apache.org/
Repository : updates
Summary : Apache HTTP Server
Source : httpd-2.4.6-80.el7.centos.1.src.rpm
Description :
The Apache HTTP Server is a powerful, efficient, and extensible
web server.
```
The **`httpd`** package is coming from **`CentOS updates repo`**.
### How Do We Find Out The Installed Packages Came From Which Repository on Fedora System?
DNF stands for Dandified yum. We can tell DNF, the next generation of yum package manager (Fork of Yum) using hawkey/libsolv library for back-end. Aleš Kozumplík started working on DNF since Fedora 18 and its implemented/launched in Fedora 22 finally.
[Dnf command][10] is used to install, update, search & remove packages on Fedora 22 and later system. It automatically resolve dependencies and make it smooth package installation without any trouble.
```
$ dnf info tilix
Last metadata expiration check: 27 days, 10:00:23 ago on Wed 04 Oct 2017 06:43:27 AM IST.
Installed Packages
Name : tilix
Version : 1.6.4
Release : 1.fc26
Arch : x86_64
Size : 3.6 M
Source : tilix-1.6.4-1.fc26.src.rpm
Repo : @System
From repo : updates
Summary : Tiling terminal emulator
URL : https://github.com/gnunn1/tilix
License : MPLv2.0 and GPLv3+ and CC-BY-SA
Description : Tilix is a tiling terminal emulator with the following features:
:
: - Layout terminals in any fashion by splitting them horizontally or vertically
: - Terminals can be re-arranged using drag and drop both within and between
: windows
: - Terminals can be detached into a new window via drag and drop
: - Input can be synchronized between terminals so commands typed in one
: terminal are replicated to the others
: - The grouping of terminals can be saved and loaded from disk
: - Terminals support custom titles
: - Color schemes are stored in files and custom color schemes can be created by
: simply creating a new file
: - Transparent background
: - Supports notifications when processes are completed out of view
:
: The application was written using GTK 3 and an effort was made to conform to
: GNOME Human Interface Guidelines (HIG).
```
The **`tilix`** package is coming from **`Fedora updates repo`**.
### How Do We Find Out The Installed Packages Came From Which Repository on openSUSE System?
Zypper is a command line package manager which makes use of libzypp. [Zypper command][11] provides functions like repository access, dependency solving, package installation, etc.
```
$ zypper info nano
Loading repository data...
Reading installed packages...
Information for package nano:
-----------------------------
Repository : Main Repository (OSS)
Name : nano
Version : 2.4.2-5.3
Arch : x86_64
Vendor : openSUSE
Installed Size : 1017.8 KiB
Installed : No
Status : not installed
Source package : nano-2.4.2-5.3.src
Summary : Pico editor clone with enhancements
Description :
GNU nano is a small and friendly text editor. It aims to emulate
the Pico text editor while also offering a few enhancements.
```
The **`nano`** package is coming from **`openSUSE Main repo (OSS)`**.
### How Do We Find Out The Installed Packages Came From Which Repository on ArchLinux System?
[Pacman command][12] stands for package manager utility. pacman is a simple command-line utility to install, build, remove and manage Arch Linux packages. Pacman uses libalpm (Arch Linux Package Management (ALPM) library) as a back-end to perform all the actions.
```
# pacman -Ss chromium
extra/chromium 48.0.2564.116-1
The open-source project behind Google Chrome, an attempt at creating a safer, faster, and more stable browser
extra/qt5-webengine 5.5.1-9 (qt qt5)
Provides support for web applications using the Chromium browser project
community/chromium-bsu 0.9.15.1-2
A fast paced top scrolling shooter
community/chromium-chromevox latest-1
Causes the Chromium web browser to automatically install and update the ChromeVox screen reader extention. Note: This
package does not contain the extension code.
community/fcitx-mozc 2.17.2313.102-1
Fcitx Module of A Japanese Input Method for Chromium OS, Windows, Mac and Linux (the Open Source Edition of Google Japanese
Input)
```
The **`chromium`** package is coming from **`ArchLinux extra repo`**.
Alternatively, we can use the following option to get the detailed information about the package.
```
# pacman -Si chromium
Repository : extra
Name : chromium
Version : 48.0.2564.116-1
Description : The open-source project behind Google Chrome, an attempt at creating a safer, faster, and more stable browser
Architecture : x86_64
URL : http://www.chromium.org/
Licenses : BSD
Groups : None
Provides : None
Depends On : gtk2 nss alsa-lib xdg-utils bzip2 libevent libxss icu libexif libgcrypt ttf-font systemd dbus
flac snappy speech-dispatcher pciutils libpulse harfbuzz libsecret libvpx perl perl-file-basedir
desktop-file-utils hicolor-icon-theme
Optional Deps : kdebase-kdialog: needed for file dialogs in KDE
gnome-keyring: for storing passwords in GNOME keyring
kwallet: for storing passwords in KWallet
Conflicts With : None
Replaces : None
Download Size : 44.42 MiB
Installed Size : 172.44 MiB
Packager : Evangelos Foutras
Build Date : Fri 19 Feb 2016 04:17:12 AM IST
Validated By : MD5 Sum SHA-256 Sum Signature
```
The **`chromium`** package is coming from **`ArchLinux extra repo`**.
### How Do We Find Out The Installed Packages Came From Which Repository on Debian Based Systems?
It can be done in two ways on Debian based systems such as Ubuntu, LinuxMint, etc.,
### Method-1: Using apt-cache Command
The [apt-cache command][13] can display much of the information stored in APT’s internal database. This information is a sort of cache since it is gathered from the different sources listed in the sources.list file. This happens during the apt update operation.
```
$ apt-cache policy python3
python3:
Installed: 3.6.3-0ubuntu2
Candidate: 3.6.3-0ubuntu3
Version table:
3.6.3-0ubuntu3 500
500 http://in.archive.ubuntu.com/ubuntu artful-updates/main amd64 Packages
* 3.6.3-0ubuntu2 500
500 http://in.archive.ubuntu.com/ubuntu artful/main amd64 Packages
100 /var/lib/dpkg/status
```
The **`python3`** package is coming from **`Ubuntu updates repo`**.
### Method-2: Using apt Command
[APT command][14] stands for Advanced Packaging Tool (APT) which is replacement for apt-get, like how DNF came to picture instead of YUM. It’s feature rich command-line tools with included all the futures in one command (APT) such as apt-cache, apt-search, dpkg, apt-cdrom, apt-config, apt-key, etc..,. and several other unique features. For example we can easily install .dpkg packages through APT but we can’t do through Apt-Get similar more features are included into APT command. APT-GET replaced by APT Due to lock of futures missing in apt-get which was not solved.
```
$ apt -a show notepadqq
Package: notepadqq
Version: 1.3.2-1~artful1
Priority: optional
Section: editors
Maintainer: Daniele Di Sarli
Installed-Size: 1,352 kB
Depends: notepadqq-common (= 1.3.2-1~artful1), coreutils (>= 8.20), libqt5svg5 (>= 5.2.1), libc6 (>= 2.14), libgcc1 (>= 1:3.0), libqt5core5a (>= 5.9.0~beta), libqt5gui5 (>= 5.7.0), libqt5network5 (>= 5.2.1), libqt5printsupport5 (>= 5.2.1), libqt5webkit5 (>= 5.6.0~rc), libqt5widgets5 (>= 5.2.1), libstdc++6 (>= 5.2)
Download-Size: 356 kB
APT-Sources: http://ppa.launchpad.net/notepadqq-team/notepadqq/ubuntu artful/main amd64 Packages
Description: Notepad++-like editor for Linux
Text editor with support for multiple programming
languages, multiple encodings and plugin support.
Package: notepadqq
Version: 1.2.0-1~artful1
Status: install ok installed
Priority: optional
Section: editors
Maintainer: Daniele Di Sarli
Installed-Size: 1,352 kB
Depends: notepadqq-common (= 1.2.0-1~artful1), coreutils (>= 8.20), libqt5svg5 (>= 5.2.1), libc6 (>= 2.14), libgcc1 (>= 1:3.0), libqt5core5a (>= 5.9.0~beta), libqt5gui5 (>= 5.7.0), libqt5network5 (>= 5.2.1), libqt5printsupport5 (>= 5.2.1), libqt5webkit5 (>= 5.6.0~rc), libqt5widgets5 (>= 5.2.1), libstdc++6 (>= 5.2)
Homepage: http://notepadqq.altervista.org
Download-Size: unknown
APT-Manual-Installed: yes
APT-Sources: /var/lib/dpkg/status
Description: Notepad++-like editor for Linux
Text editor with support for multiple programming
languages, multiple encodings and plugin support.
```
The **`notepadqq`** package is coming from **`Launchpad PPA`**.
--------------------------------------------------------------------------------
via: https://www.2daygeek.com/how-do-we-find-out-the-installed-packages-came-from-which-repository/
作者：[Prakash Subramanian][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://www.2daygeek.com/author/prakash/
[b]: https://github.com/lujun9972
[1]: https://www.2daygeek.com/category/repository/
[2]: https://www.2daygeek.com/install-enable-epel-repository-on-rhel-centos-scientific-linux-oracle-linux/
[3]: https://www.2daygeek.com/install-enable-elrepo-on-rhel-centos-scientific-linux/
[4]: https://www.2daygeek.com/additional-yum-repositories-for-centos-rhel-fedora-systems/
[5]: https://www.2daygeek.com/install-enable-rpm-fusion-repository-on-centos-fedora-rhel/
[6]: https://fedoraproject.org/wiki/Third_party_repositories
[7]: https://www.2daygeek.com/install-enable-packman-repository-on-opensuse-leap/
[8]: https://www.2daygeek.com/yum-command-examples-manage-packages-rhel-centos-systems/
[9]: https://www.2daygeek.com/rpm-command-examples/
[10]: https://www.2daygeek.com/dnf-command-examples-manage-packages-fedora-system/
[11]: https://www.2daygeek.com/zypper-command-examples-manage-packages-opensuse-system/
[12]: https://www.2daygeek.com/pacman-command-examples-manage-packages-arch-linux-system/
[13]: https://www.2daygeek.com/apt-get-apt-cache-command-examples-manage-packages-debian-ubuntu-systems/
[14]: https://www.2daygeek.com/apt-command-examples-manage-packages-debian-ubuntu-systems/

2
sources/tech/20181031 8 creepy commands that haunt the terminal - Opensource.com.md
View File

@ -1,3 +1,5 @@
translating---geekpi
8 creepy commands that haunt the terminal | Opensource.com
======

407
sources/tech/20181101 Getting started with OKD on your Linux desktop.md Normal file
View File

@ -0,0 +1,407 @@
Getting started with a local OKD cluster on Linux
======
Try out OKD, the community edition of the OpenShift container platform, with this tutorial.
![](https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/linux-penguin.png?itok=8sDDLbcR)
OKD is the open source upstream community edition of Red Hat's OpenShift container platform. OKD is a container management and orchestration platform based on [Docker][1] and [Kubernetes][2].
OKD is a complete solution to manage, deploy, and operate containerized applications that (in addition to the features provided by Kubernetes) includes an easy-to-use web interface, automated build tools, routing capabilities, and monitoring and logging aggregation features.
OKD provides several deployment options aimed at different requirements with single or multiple master nodes, high-availability capabilities, logging, monitoring, and more. You can create OKD clusters as small or as large as you need.
In addition to these deployment options, OKD provides a way to create a local, all-in-one cluster on your own machine using the oc command-line tool. This is a great option if you want to try OKD locally without committing the resources to create a larger multi-node cluster, or if you want to have a local cluster on your machine as part of your workflow or development process. In this case, you can create and deploy the applications locally using the same APIs and interfaces required to deploy the application on a larger scale. This process ensures a seamless integration that prevents issues with applications that work in the developer's environment but not in production.
This tutorial will show you how to create an OKD cluster using **oc cluster up** in a Linux box.
### 1\. Install Docker
The **oc cluster up** command creates a local OKD cluster on your machine using Docker containers. In order to use this command, you need Docker installed on your machine. For OKD version 3.9 and later, Docker 1.13 is the minimum recommended version. If Docker is not installed on your system, install it by using your distribution package manager. For example, on CentOS or RHEL, install Docker with this command:
```
$ sudo yum install -y docker
```
On Fedora, use dnf:
```
$ sudo dnf install -y docker
```
This installs Docker and all required dependencies.
### 2\. Configure Docker insecure registry
Once you have Docker installed, you need to configure it to allow the communication with an insecure registry on address 172.30.0.0/16. This insecure registry will be deployed with your local OKD cluster later.
On CentOS or RHEL, edit the file **/etc/docker/daemon.json** by adding these lines:
```
{
        "insecure-registries": ["172.30.0.0/16"]
}
```
On Fedora, edit the file **/etc/containers/registries.conf** by adding these lines:
```
[registries.insecure]
registries = ['172.30.0.0/16']
```
### 3\. Start Docker
Before starting Docker, create a system group named **docker** and assign this group to your user so you can run Docker commands with your own user, without requiring root or sudo access. This allows you to create your OKD cluster using your own user.
For example, these are the commands to create the group and assign it to my local user, **ricardo** :
```
$ sudo groupadd docker
$ sudo usermod -a -G docker ricardo
```
You need to log out and log back in to see the new group association. After logging back in, run the **id** command and ensure you're a member of the **docker** group:
```
$ id
uid=1000(ricardo) gid=1000(ricardo) groups=1000(ricardo),10(wheel),1001(docker)
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
```
Now, start and enable the Docker daemon like this:
```
$ sudo systemctl start docker
$ sudo systemctl enable docker
Created symlink from /etc/systemd/system/multi-user.target.wants/docker.service to /usr/lib/systemd/system/docker.service.
```
Verify that Docker is running:
```
$ docker version
Client:
 Version:         1.13.1
 API version:     1.26
 Package version: docker-1.13.1-75.git8633870.el7.centos.x86_64
 Go version:      go1.9.4
 Git commit:      8633870/1.13.1
 Built:           Fri Sep 28 19:45:08 2018
 OS/Arch:         linux/amd64
Server:
 Version:         1.13.1
 API version:     1.26 (minimum version 1.12)
 Package version: docker-1.13.1-75.git8633870.el7.centos.x86_64
 Go version:      go1.9.4
 Git commit:      8633870/1.13.1
 Built:           Fri Sep 28 19:45:08 2018
 OS/Arch:         linux/amd64
 Experimental:    false
```
Ensure that the insecure registry option has been enabled by running **docker info** and looking for these lines:
```
$ docker info
... Skipping long output ...
Insecure Registries:
 172.30.0.0/16
 127.0.0.0/8
```
### 4\. Open firewall ports
Next, open firewall ports to ensure your OKD containers can communicate with the master API. By default, some distributions have the firewall enabled, which blocks required connectivity from the OKD containers to the master API. If your system has the firewall enabled, you need to add rules to allow communication on ports **8443/tcp** for the master API and **53/udp** for DNS resolution on the Docker bridge subnet.
For CentOS, RHEL, and Fedora, you can use the **firewall-cmd** command-line tool to add the rules. For other distributions, you can use the provided firewall manager, such as [UFW][3] or [iptables][4].
Before adding the firewall rules, obtain the Docker bridge network subnet's address, like this:
```
$ docker network inspect bridge | grep Subnet
                    "Subnet": "172.17.0.0/16",
```
Enable the firewall rules using this subnet. For CentOS, RHEL, and Fedora, use **firewall-cmd** to add a new zone:
```
$ sudo firewall-cmd --permanent --new-zone okdlocal
success
```
Include the subnet address you obtained before as a source to the new zone:
```
$ sudo firewall-cmd --permanent --zone okdlocal --add-source 172.17.0.0/16
success
```
Next, add the required rules to the **okdlocal** zone:
```
$ sudo firewall-cmd --permanent --zone okdlocal --add-port 8443/tcp
success
$ sudo firewall-cmd --permanent --zone okdlocal --add-port 53/udp
success
$ sudo firewall-cmd --permanent --zone okdlocal --add-port 8053/udp
success
```
Finally, reload the firewall to enable the new rules:
```
$ sudo firewall-cmd --reload
success
```
Ensure that the new zone and rules are in place:
```
$ sudo firewall-cmd --zone okdlocal --list-sources
172.17.0.0/16
$ sudo firewall-cmd --zone okdlocal --list-ports
8443/tcp 53/udp 8053/udp
```
Your system is ready to start the cluster. It's time to download the OKD client tools.
To deploy a local OKD cluster using **oc** , you need to download the OKD client tools package. For some distributions, like CentOS and Fedora, this package can be downloaded as an RPM from the official repositories. Please note that these packages may follow the distribution update cycle and usually are not the most recent version available.
For this tutorial, download the OKD client package directly from the official GitHub repository so you can get the most recent version available. At the time of writing, this was OKD v3.11.
Go to the [OKD downloads page][5] to get the link to the OKD tools for Linux, then download it with **wget** :
```
$ cd ~/Downloads/
$ wget https://github.com/openshift/origin/releases/download/v3.11.0/openshift-origin-client-tools-v3.11.0-0cbc58b-linux-64bit.tar.gz
```
Uncompress the downloaded package:
```
$ tar -xzvf openshift-origin-client-tools-v3.11.0-0cbc58b-linux-64bit.tar.gz
```
Finally, to make it easier to use the **oc** command systemwide, move it to a directory included in your **$PATH** variable. A good location is **/usr/local/bin** :
```
$ sudo cp openshift-origin-client-tools-v3.11.0-0cbc58b-linux-64bit/oc /usr/local/bin/
```
One of the nicest features of the **oc** command is that it's a static single binary. You don't need to install it to use it.
Check that the **oc** command is working:
```
$ oc version
oc v3.11.0+0cbc58b
kubernetes v1.11.0+d4cacc0
features: Basic-Auth GSSAPI Kerberos SPNEGO
```
### 6\. Start your OKD cluster
Once you have all the prerequisites in place, start your local OKD cluster by running this command:
```
$ oc cluster up
```
This command connects to your local Docker daemon, downloads all required images from Docker Hub, and starts the containers. The first time you run it, it takes a few minutes to complete. When it's finished, you will see this message:
```
... Skipping long output ...
OpenShift server started.
The server is accessible via web console at:
    https://127.0.0.1:8443
You are logged in as:
    User:     developer
    Password: <any value>
To login as administrator:
    oc login -u system:admin
```
Access the OKD web console by using the browser and navigating to <https://127.0.0.1:8443:>
![](https://opensource.com/sites/default/files/uploads/okd-login.png)
From the command line, you can check if the cluster is running by entering this command:
```
$ oc cluster status
Web console URL: https://127.0.0.1:8443/console/
Config is at host directory
Volumes are at host directory
Persistent volumes are at host directory /home/ricardo/openshift.local.clusterup/openshift.local.pv
Data will be discarded when cluster is destroyed
```
You can also verify your cluster is working by logging in as the **system:admin** user and checking available nodes using the **oc** command-line tool:
```
$ oc login -u system:admin
Logged into "https://127.0.0.1:8443" as "system:admin" using existing credentials.
You have access to the following projects and can switch between them with 'oc project <projectname>':
    default
    kube-dns
    kube-proxy
    kube-public
    kube-system
  * myproject
    openshift
    openshift-apiserver
    openshift-controller-manager
    openshift-core-operators
    openshift-infra
    openshift-node
    openshift-service-cert-signer
    openshift-web-console
Using project "myproject".
$ oc get nodes
NAME        STATUS    ROLES     AGE       VERSION
localhost   Ready     <none>    52m       v1.11.0+d4cacc0
```
Since this is a local, all-in-one cluster, you see only **localhost** in the nodes list.
### 7\. Smoke-test your cluster
Now that your local OKD cluster is running, create a test app to smoke-test it. Use OKD to build and start the sample application so you can ensure the different components are working.
Start by logging in as the **developer** user:
```
$ oc login -u developer
Logged into "https://127.0.0.1:8443" as "developer" using existing credentials.
You have one project on this server: "myproject"
Using project "myproject".
```
You're automatically assigned to a new, empty project named **myproject**. Create a sample PHP application based on an existing GitHub repository, like this:
```
$ oc new-app php:5.6~https://github.com/rgerardi/ocp-smoke-test.git
--> Found image 92ed8b3 (5 months old) in image stream "openshift/php" under tag "5.6" for "php:5.6"
    Apache 2.4 with PHP 5.6
    -----------------------
    PHP 5.6 available as container is a base platform for building and running various PHP 5.6 applications and frameworks. PHP is an HTML-embedded scripting language. PHP attempts to make it easy for developers to write dynamically generated web pages. PHP also offers built-in database integration for several commercial and non-commercial database management systems, so writing a database-enabled webpage with PHP is fairly simple. The most common use of PHP coding is probably as a replacement for CGI scripts.
    Tags: builder, php, php56, rh-php56
    * A source build using source code from https://github.com/rgerardi/ocp-smoke-test.git will be created
      * The resulting image will be pushed to image stream tag "ocp-smoke-test:latest"
      * Use 'start-build' to trigger a new build
    * This image will be deployed in deployment config "ocp-smoke-test"
    * Ports 8080/tcp, 8443/tcp will be load balanced by service "ocp-smoke-test"
      * Other containers can access this service through the hostname "ocp-smoke-test"
--> Creating resources ...
    imagestream.image.openshift.io "ocp-smoke-test" created
    buildconfig.build.openshift.io "ocp-smoke-test" created
    deploymentconfig.apps.openshift.io "ocp-smoke-test" created
    service "ocp-smoke-test" created
--> Success
    Build scheduled, use 'oc logs -f bc/ocp-smoke-test' to track its progress.
    Application is not exposed. You can expose services to the outside world by executing one or more of the commands below:
     'oc expose svc/ocp-smoke-test'
    Run 'oc status' to view your app.
```
OKD starts the build process, which clones the provided GitHub repository, compiles the application (if required), and creates the necessary images. You can follow the build process by tailing its log with this command:
```
$ oc logs -f bc/ocp-smoke-test
Cloning "https://github.com/rgerardi/ocp-smoke-test.git" ...
        Commit: 391a475713d01ab0afab700bab8a3d7549c5cc27 (Create index.php)
        Author: Ricardo Gerardi <ricardo.gerardi@gmail.com>
        Date:   Tue Oct 2 13:47:25 2018 -0400
Using 172.30.1.1:5000/openshift/php@sha256:f3c95020fa870fcefa7d1440d07a2b947834b87bdaf000588e84ef4a599c7546 as the s2i builder image
---> Installing application source...
=> sourcing 20-copy-config.sh ...
---> 04:53:28     Processing additional arbitrary httpd configuration provided by s2i ...
=> sourcing 00-documentroot.conf ...
=> sourcing 50-mpm-tuning.conf ...
=> sourcing 40-ssl-certs.sh ...
Pushing image 172.30.1.1:5000/myproject/ocp-smoke-test:latest ...
Pushed 1/10 layers, 10% complete
Push successful
```
After the build process completes, OKD starts the application automatically by running a new pod based on the created image. You can see this new pod with this command:
```
$ oc get pods
NAME                     READY     STATUS      RESTARTS   AGE
ocp-smoke-test-1-build   0/1       Completed   0          1m
ocp-smoke-test-1-d8h76   1/1       Running     0          7s
```
You can see two pods are created; the first one (with the status Completed) is the pod used to build the application. The second one (with the status Running) is the application itself.
In addition, OKD creates a service for this application. Verify it by using this command:
```
$ oc get service
NAME             TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)             AGE
ocp-smoke-test   ClusterIP   172.30.232.241   <none>        8080/TCP,8443/TCP   1m
```
Finally, expose this service externally using OKD routes so you can access the application from a local browser:
```
$ oc expose svc ocp-smoke-test
route.route.openshift.io/ocp-smoke-test exposed
$ oc get route
NAME             HOST/PORT                                   PATH      SERVICES         PORT       TERMINATION   WILDCARD
ocp-smoke-test   ocp-smoke-test-myproject.127.0.0.1.nip.io             ocp-smoke-test   8080-tcp                 None
```
Verify that your new application is running by navigating to <http://ocp-smoke-test-myproject.127.0.0.1.nip.io> in a web browser:
![](https://opensource.com/sites/default/files/uploads/okd-smoke-test-app.png)
You can also see the status of your application by logging into the OKD web console:
![](https://opensource.com/sites/default/files/uploads/okd-smoke-test.png)
### Learn more
You can find more information about OKD on the [official site][6], which includes a link to the OKD [documentation][7].
If this is your first time working with OKD/OpenShift, you can learn the basics of the platform, including how to build and deploy containerized applications, through the [Interactive Learning Portal][8]. Another good resource is the official [OpenShift YouTube channel][9].
--------------------------------------------------------------------------------
via: https://opensource.com/article/18/11/local-okd-cluster-linux
作者：[Ricardo Gerardi][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/rgerardi
[b]: https://github.com/lujun9972
[1]: https://www.docker.com/
[2]: https://kubernetes.io/
[3]: https://en.wikipedia.org/wiki/Uncomplicated_Firewall
[4]: https://en.wikipedia.org/wiki/Iptables
[5]: https://www.okd.io/download.html#oc-platforms
[6]: https://www.okd.io/
[7]: https://docs.okd.io/
[8]: https://learn.openshift.com/
[9]: https://www.youtube.com/openshift

75
sources/tech/20181101 KRS- A new tool for gathering Kubernetes resource statistics.md Normal file
View File

@ -0,0 +1,75 @@
KRS: A new tool for gathering Kubernetes resource statistics
======
Zero-configuration tool simplifies gathering information, such as how many pods are running in a certain namespace.
![](https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/tools_hardware_purple.png?itok=3NdVoYhl)
Recently I was in New York giving a talk at O'Reilly Velocity on the topic of [troubleshooting Kubernetes apps][1] and, motivated by the positive feedback and great discussions on the topic, I decided to revisit tooling in the space. It turns out that, besides [kubernetes-incubator/spartakus][2] and [kubernetes/kube-state-metrics][3], we don't really have much lightweight tooling available to collect resource stats (such as the number of pods or services in a namespace). So, I sat down on my way home and started coding on a little tool—creatively named **krs** , which is short for Kubernetes Resource Stats—that allows you to gather these stats.
You can use [mhausenblas/krs][5] in two ways:
* directly from the command line (binaries for Linux, Windows, and MacOS are available); and
* in cluster, as a deployment, using the [launch.sh][4] script, which creates the appropriate role-based access control (RBAC) permissions on the fly.
Mind you, it's very early days, and this is heavily a work in progress. However, the 0.1 release of **krs** offers the following features:
* In a per-namespace basis, it periodically gathers resource stats (supporting pods, deployments, and services).
* It exposes these stats as metrics in the [OpenMetrics format][6].
* It can be used directly via binaries or in a containerized setup with all dependencies included.
In its current form, you need to have **kubectl** installed and configured for **krs** to work, because **krs** relies on a **kubectl get all** command to be executed to gather the stats. (On the other hand, who's using Kubernetes and doesn't have **kubectl** installed?)
Using **krs** is simple; [Download][7] the binary for your platform and execute it like this:
```
$ krs thenamespacetowatch
# HELP pods Number of pods in any state, for example running
# TYPE pods gauge
pods{namespace="thenamespacetowatch"} 13
# HELP deployments Number of deployments
# TYPE deployments gauge
deployments{namespace="thenamespacetowatch"} 6
# HELP services Number of services
# TYPE services gauge
services{namespace="thenamespacetowatch"} 4
```
This will launch **krs** in the foreground, gathering resource stats from the namespace **thenamespacetowatch** and outputting them respectively in the OpenMetrics format on **stdout** for you to further process.
![krs screenshot][9]
Screenshot of krs in action.
But Michael, you may ask, why isn't it doing something useful (such as storing 'em in S3) with the metrics? Because [Unix philosophy][10].
For those wondering if they can directly use Prometheus or [kubernetes/kube-state-metrics][3] for this task: Well, sure you can, why not? The emphasis of **krs** is on being a lightweight and easy-to-use alternative to already available tooling—and maybe even being slightly complementary in certain aspects.
This was originally published on [Medium's ITNext][11] and is reprinted with permission.
--------------------------------------------------------------------------------
via: https://opensource.com/article/18/11/kubernetes-resource-statistics
作者：[Michael Hausenblas][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/mhausenblas
[b]: https://github.com/lujun9972
[1]: http://troubleshooting.kubernetes.sh/
[2]: https://github.com/kubernetes-incubator/spartakus
[3]: https://github.com/kubernetes/kube-state-metrics
[4]: https://github.com/mhausenblas/krs/blob/master/launch.sh
[5]: https://github.com/mhausenblas/krs
[6]: https://openmetrics.io/
[7]: https://github.com/mhausenblas/krs/releases
[8]: /file/412706
[9]: https://opensource.com/sites/default/files/uploads/krs_screenshot.png (krs screenshot)
[10]: http://harmful.cat-v.org/cat-v/
[11]: https://itnext.io/kubernetes-resource-statistics-e8247f92b45c

168
translated/tech/20180810 How To Quickly Serve Files And Folders Over HTTP In Linux.md Normal file
View File

@ -0,0 +1,168 @@
如何在 Linux 中快速地通过 HTTP 访问文件和文件夹
======
![](https://www.ostechnix.com/wp-content/uploads/2018/08/http-720x340.png)
今天，我有很多方法来通过网络浏览器为局域网中的其他系统提供单个文件或整个目录访问。我在我的 Ubuntu 测试机上测试了这些方法，它们和下面描述的那样运行正常。如果你想知道如何在类 Unix 操作系统中通过 HTTP 轻松快速地访问文件和文件夹，以下方法之一肯定会有所帮助。
### 在 Linux 中通过 HTTP 访问文件和文件夹
**免责声明：**此处给出的所有方法适用于安全的局域网。由于这些方法没有任何安全机制，因此**不建议在生产环境中使用它们**。你注意了！
#### 方法 1 - 使用 simpleHTTPserver（Python）
我们写了一篇简要的指南来设置一个简单的 http 服务器，以便在以下链接中即时共享文件和目录。如果你有一个安装了 Python 的系统，这个方法非常方便。
#### 方法 2 - 使用 Quickserve（Python）
此方法针对 Arch Linux 及其衍生版。有关详细信息，请查看下面的链接。
#### 方法 3 - 使用 Ruby
在此方法中，我们使用 Ruby 在类 Unix 系统中通过 HTTP 提供文件和文件夹访问。按照以下链接中的说明安装 Ruby 和 Rails。
安装 Ruby 后，进入要通过网络共享的目录，例如 ostechnix：
```
$ cd ostechnix
```
并运行以下命令：
```
$ ruby -run -ehttpd . -p8000
[2018-08-10 16:02:55] INFO WEBrick 1.4.2
[2018-08-10 16:02:55] INFO ruby 2.5.1 (2018-03-29) [x86_64-linux]
[2018-08-10 16:02:55] INFO WEBrick::HTTPServer#start: pid=5859 port=8000
```
确保在路由器或防火墙中打开端口 8000。如果该端口已被其他一些服务使用，那么请使用不同的端口。
现在你可以使用 URL 从任何远程系统访问此文件夹的内容 - **http:// <ip-address>:8000**。
![](https://www.ostechnix.com/wp-content/uploads/2018/08/ruby-http-server.png)
要停止共享，请按 **CTRL+C**。
#### 方法 4 - 使用 Http-server（NodeJS）
[**Http-server**][1] 是一个用 NodeJS 编写的简单的可用于生产的命令行 http-server。它不需要要配置，可用于通过 Web 浏览器即时共享文件和目录。
按如下所述安装 NodeJS。
安装 NodeJS 后，运行以下命令安装 http-server。
```
$ npm install -g http-server
```
现在进入任何目录并通过 HTTP 共享其内容，如下所示。
```
$ cd ostechnix
$ http-server -p 8000
Starting up http-server, serving ./
Available on:
http://127.0.0.1:8000
http://192.168.225.24:8000
http://192.168.225.20:8000
Hit CTRL-C to stop the server
```
现在你可以使用 URL 从任何远程系统访问此文件夹的内容 - **http:// <ip-address>:8000**。
![](http://www.ostechnix.com/wp-content/uploads/2018/08/nodejs-http-server.png)
要停止共享，请按 **CTRL+C**。
#### 方法 5 - 使用 Miniserve（Rust）
[**Miniserve**][2] 是另一个命令行程序，它允许你通过 HTTP 快速访问文件。它是一个非常快速，易于使用的跨平台程序，它用 **Rust** 编程语言编写。与上面的程序/方法不同，它提供身份验证支持，因此你可以为共享设置用户名和密码。
按下面的链接在 Linux 系统中安装 Rust。
安装 Rust 后，运行以下命令安装 miniserve：
```
$ cargo install miniserve
```
或者，你可以在[**发布页**][3]下载二进制文件并使其可执行。
```
$ chmod +x miniserve-linux
```
然后，你可以使用命令运行它（假设 miniserve 二进制文件下载到当前的工作目录中）：
```
$ ./miniserve-linux <path-to-share>
```
**用法**
要提供目录访问：
```
$ miniserve <path-to-directory>
```
**示例：**
```
$ miniserve /home/sk/ostechnix/
miniserve v0.2.0
Serving path /home/sk/ostechnix at http://[::]:8080, http://localhost:8080
Quit by pressing CTRL-C
```
现在，你可以在本地系统使用 URL – **<http://localhost:8080>** 访问共享，或者在远程系统使用 URL – **http:// <ip-address>:8080** 访问。
要提供单个文件访问：
```
$ miniserve <path-to-file>
```
**示例：**
```
$ miniserve ostechnix/file.txt
```
带用户名和密码提供文件/文件夹访问：
```
$ miniserve --auth joe:123 <path-to-share>
```
绑定到多个接口：
```
$ miniserve -i 192.168.225.1 -i 10.10.0.1 -i ::1 -- <path-to-share>
```
如你所见，我只给出了 5 种方法。但是，本指南末尾附带的链接中还提供了几种方法。也去测试一下它们。此外，收藏并时不时重新访问它来检查将来是否有新的方法。
今天就是这些。希望这篇文章有用。还有更多的好东西。敬请期待！
干杯！
--------------------------------------------------------------------------------
via: https://www.ostechnix.com/how-to-quickly-serve-files-and-folders-over-http-in-linux/
作者：[SK][a]
选题：[lujun9972](https://github.com/lujun9972)
译者：[geekpi](https://github.com/geekpi)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://www.ostechnix.com/author/sk/
[1]:https://www.npmjs.com/package/http-server
[2]:https://github.com/svenstaro/miniserve
[3]:https://github.com/svenstaro/miniserve/releases