mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-25 23:11:02 +08:00
Merge remote-tracking branch 'LCTT/master'
This commit is contained in:
Xingyu Wang
commit
4f1bc0075e
61
published/20191015 How GNOME uses Git.md
Normal file
61
published/20191015 How GNOME uses Git.md
Normal file
@ -0,0 +1,61 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (wxy)
|
||||
[#]: reviewer: (wxy)
|
||||
[#]: publisher: (wxy)
|
||||
[#]: url: (https://linux.cn/article-11806-1.html)
|
||||
[#]: subject: (How GNOME uses Git)
|
||||
[#]: via: (https://opensource.com/article/19/10/how-gnome-uses-git)
|
||||
[#]: author: (Molly de Blanc https://opensource.com/users/mollydb)
|
||||
|
||||
一个非技术人员对 GNOME 项目使用 GitLab 的感受
|
||||
======
|
||||
|
||||
> 将 GNOME 项目集中在 GitLab 上的决定为整个社区（不只是开发人员）带来了好处。
|
||||
|
||||
![red panda][1]
|
||||
|
||||
“您的 GitLab 是什么？”这是我在 [GNOME 基金会][2]工作的第一天被问到的第一个问题之一，该基金会是支持 GNOME 项目（包括[桌面环境][3]、[GTK][4] 和 [GStreamer][5]）的非盈利组织。此人问的是我在 [GNOME 的 GitLab 实例][6]上的用户名。我在 GNOME 期间，经常有人要求我提供我的 GitLab。
|
||||
|
||||
我们使用 GitLab 进行几乎所有操作。通常情况下，我会收到一些<ruby>提案<rt>issue</rt></ruby>和参考错误报告，有时还需要修改文件。我不是以开发人员或系统管理员的身份进行此操作的。我参与了“参与度、包容性和多样性（I＆D）”团队。我为 GNOME 朋友们撰写新闻通讯，并采访该项目的贡献者。我为 GNOME 活动提供赞助。我不写代码，但我每天都使用 GitLab。
|
||||
|
||||
在过去的二十年中，GNOME 项目的管理采用了各种方式。该项目的不同部分使用不同的系统来跟踪代码更改、协作以及作为项目和社交空间共享信息。但是，该项目决定，它需要更加地一体化，这从构思到完成大约花费了一年的时间。
|
||||
|
||||
GNOME 希望切换到单个工具供整个社区使用的原因很多。外部项目与 GNOME 息息相关，并为它们提供更简单的与资源交互的方式对于项目至关重要，无论是支持社区还是发展生态系统。我们还希望更好地跟踪 GNOME 的指标，即贡献者的数量、贡献的类型和数量以及项目不同部分的开发进度。
|
||||
|
||||
当需要选择一种协作工具时，我们考虑了我们需要的东西。最重要的要求之一是它必须由 GNOME 社区托管。由第三方托管并不是一种选择，因此像 GitHub 和 Atlassian 这样的服务就不在考虑之中。而且，当然了，它必须是自由软件。很快，唯一真正的竞争者出现了，它就是 GitLab。我们希望确保进行贡献很容易。GitLab 具有诸如单点登录的功能，该功能允许人们使用 GitHub、Google、GitLab.com 和 GNOME 帐户登录。
|
||||
|
||||
我们认为 GitLab 是一条出路，我们开始从许多工具迁移到单个工具。GNOME 董事会成员 [Carlos Soriano][7] 领导这项改变。在 GitLab 和 GNOME 社区的大力支持下，我们于 2018 年 5 月完成了该过程。
|
||||
|
||||
人们非常希望迁移到 GitLab 有助于社区的发展，并使贡献更加容易。由于 GNOME 以前使用了许多不同的工具，包括 Bugzilla 和 CGit，因此很难定量地评估这次切换对贡献量的影响。但是，我们可以更清楚地跟踪一些统计数据，例如在 2018 年 6 月至 2018 年 11 月之间关闭了近 10,000 个提案，合并了 7,085 个合并请求。人们感到社区在发展壮大，越来越受欢迎，而且贡献实际上也更加容易。
|
||||
|
||||
人们因不同的原因而开始使用自由软件，重要的是，可以通过为需要软件的人提供更好的资源和更多的支持来公平竞争。Git 作为一种工具已被广泛使用，并且越来越多的人使用这些技能来参与到自由软件当中。自托管的 GitLab 提供了将 Git 的熟悉度与 GitLab 提供的功能丰富、用户友好的环境相结合的绝佳机会。
|
||||
|
||||
切换到 GitLab 已经一年多了，变化确实很明显。持续集成（CI）为开发带来了巨大的好处，并且已经完全集成到 GNOME 的几乎每个部分当中。不进行代码开发的团队也转而使用 GitLab 生态系统进行工作。无论是使用问题跟踪来管理分配的任务，还是使用版本控制来共享和管理资产，就连“参与度、包容性和多样性（I＆D）”这样的团队都已经使用了 GitLab。
|
||||
|
||||
一个社区，即使是一个正在开发的自由软件，也很难适应新技术或新工具。在类似 GNOME 的情况下，这尤其困难，该项目[最近已经 22 岁了] [8]。像 GNOME 这样经过了 20 多年建设的项目，太多的人和组织使用了太多的部件，但迁移工作之所以能实现，这要归功于 GNOME 社区的辛勤工作和 GitLab 的慷慨帮助。
|
||||
|
||||
在为使用 Git 进行版本控制的项目工作时，我发现很方便。这是一个令人感觉舒适和熟悉的系统，是一个在工作场所和爱好项目之间保持一致的工具。作为 GNOME 社区的新成员，能够参与并使用 GitLab 真是太好了。作为社区建设者，看到这样结果是令人鼓舞的：越来越多的相关项目加入并进入生态系统；新的贡献者和社区成员对该项目做出了首次贡献；以及增强了衡量我们正在做的工作以了解其成功和成功的能力。
|
||||
|
||||
如此多的做着完全不同的事情（例如他们正在从事的不同工作以及所使用的不同技能）的团队同意汇集在一个工具上（尤其是被认为是跨开源的标准工具），这一点很棒。作为 GNOME 的贡献者，我真的非常感谢我们使用了 GitLab。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/19/10/how-gnome-uses-git
|
||||
|
||||
作者：[Molly de Blanc][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[wxy](https://github.com/wxy)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/mollydb
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/redpanda_firefox_pet_animal.jpg?itok=aSpKsyna (red panda)
|
||||
[2]: https://www.gnome.org/foundation/
|
||||
[3]: https://gnome.org/
|
||||
[4]: https://www.gtk.org/
|
||||
[5]: https://gstreamer.freedesktop.org/
|
||||
[6]: https://gitlab.gnome.org/
|
||||
[7]: https://twitter.com/csoriano1618?lang=en
|
||||
[8]: https://opensource.com/article/19/8/poll-favorite-gnome-version
|
||||
@ -1,60 +0,0 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (How GNOME uses Git)
|
||||
[#]: via: (https://opensource.com/article/19/10/how-gnome-uses-git)
|
||||
[#]: author: (Molly de Blanc https://opensource.com/users/mollydb)
|
||||
|
||||
How GNOME uses Git
|
||||
======
|
||||
The GNOME project's decision to centralize on GitLab is creating
|
||||
benefits across the community—even beyond the developers.
|
||||
![red panda][1]
|
||||
|
||||
“What’s your GitLab?” is one of the first questions I was asked on my first day working for the [GNOME Foundation][2]—the nonprofit that supports GNOME projects, including the [desktop environment][3], [GTK][4], and [GStreamer][5]. The person was referring to my username on [GNOME’s GitLab instance][6]. In my time with GNOME, I’ve been asked for my GitLab a lot.
|
||||
|
||||
We use GitLab for basically everything. In a typical day, I get several issues and reference bug reports, and I occasionally need to modify a file. I don’t do this in the capacity of being a developer or a sysadmin. I’m involved with the Engagement and Inclusion & Diversity (I&D) teams. I write newsletters for Friends of GNOME and interview contributors to the project. I work on sponsorships for GNOME events. I don’t write code, and I use GitLab every day.
|
||||
|
||||
The GNOME project has been managed a lot of ways over the past two decades. Different parts of the project used different systems to track changes to code, collaborate, and share information both as a project and as a social space. However, the project made the decision that it needed to become more integrated and it took about a year from conception to completion.
|
||||
|
||||
There were a number of reasons GNOME wanted to switch to a single tool for use across the community. External projects touch GNOME, and providing them an easier way to interact with resources was important for the project, both to support the community and to grow the ecosystem. We also wanted to better track metrics for GNOME—the number of contributors, the type and number of contributions, and the developmental progress of different parts of the project.
|
||||
|
||||
When it came time to pick a collaboration tool, we considered what we needed. One of the most important requirements was that it must be hosted by the GNOME community; being hosted by a third party didn’t feel like an option, so that discounted services like GitHub and Atlassian. And, of course, it had to be free software. It quickly became obvious that the only real contender was GitLab. We wanted to make sure contribution would be easy. GitLab has features like single sign-on, which allows people to use GitHub, Google, GitLab.com, and GNOME accounts.
|
||||
|
||||
We agreed that GitLab was the way to go, and we began to migrate from many tools to a single tool. GNOME board member [Carlos Soriano][7] led the charge. With lots of support from GitLab and the GNOME community, we completed the process in May 2018.
|
||||
|
||||
There was a lot of hope that moving to GitLab would help grow the community and make contributing easier. Because GNOME previously used so many different tools, including Bugzilla and CGit, it’s hard to quantitatively measure how the switch has impacted the number of contributions. We can more clearly track some statistics though, such as the nearly 10,000 issues closed and 7,085 merge requests merged between June and November 2018. People feel that the community has grown and become more welcoming and that contribution is, in fact, easier.
|
||||
|
||||
People come to free software from all sorts of different starting points, and it’s important to try to even out the playing field by providing better resources and extra support for people who need them. Git, as a tool, is widely used, and more people are coming to participate in free software with those skills ready to go. Self-hosting GitLab provides the perfect opportunity to combine the familiarity of Git with the feature-rich, user-friendly environment provided by GitLab.
|
||||
|
||||
It’s been a little over a year, and the change is really noticeable. Continuous integration (CI) has been a huge benefit for development, and it has been completely integrated into nearly every part of GNOME. Teams that aren’t doing code development have also switched to using the GitLab ecosystem for their work. Whether it’s using issue tracking to manage assigned tasks or version control to share and manage assets, even teams like Engagement and I&D have taken up using GitLab.
|
||||
|
||||
It can be hard for a community, even one developing free software, to adapt to a new technology or tool. It is especially hard in a case like GNOME, a project that [recently turned 22][8]. After more than two decades of building a project like GNOME, with so many parts used by so many people and organizations, the migration was an endeavor that was only possible thanks to the hard work of the GNOME community and generous assistance from GitLab.
|
||||
|
||||
I find a lot of convenience in working for a project that uses Git for version control. It’s a system that feels comfortable and is familiar—it’s a tool that is consistent across workplaces and hobby projects. As a new member of the GNOME community, it was great to be able to jump in and just use GitLab. As a community builder, it’s inspiring to see the results: more associated projects coming on board and entering the ecosystem; new contributors and community members making their first contributions to the project; and increased ability to measure the work we’re doing to know it’s effective and successful.
|
||||
|
||||
It’s great that so many teams doing completely different things (such as what they’re working on and what skills they’re using) agree to centralize on any tool—especially one that is considered a standard across open source. As a contributor to GNOME, I really appreciate that we’re using GitLab.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/19/10/how-gnome-uses-git
|
||||
|
||||
作者：[Molly de Blanc][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/mollydb
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/redpanda_firefox_pet_animal.jpg?itok=aSpKsyna (red panda)
|
||||
[2]: https://www.gnome.org/foundation/
|
||||
[3]: https://gnome.org/
|
||||
[4]: https://www.gtk.org/
|
||||
[5]: https://gstreamer.freedesktop.org/
|
||||
[6]: https://gitlab.gnome.org/
|
||||
[7]: https://twitter.com/csoriano1618?lang=en
|
||||
[8]: https://opensource.com/article/19/8/poll-favorite-gnome-version
|
||||
@ -1,109 +0,0 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (Get started with this open source to-do list manager)
|
||||
[#]: via: (https://opensource.com/article/20/1/open-source-to-do-list)
|
||||
[#]: author: (Kevin Sonney https://opensource.com/users/ksonney)
|
||||
|
||||
Get started with this open source to-do list manager
|
||||
======
|
||||
Todo is a powerful way to keep track of your task list. Learn how to use
|
||||
it in the seventh in our series on 20 ways to be more productive with
|
||||
open source in 2020.
|
||||
![Team checklist][1]
|
||||
|
||||
Last year, I brought you 19 days of new (to you) productivity tools for 2019. This year, I'm taking a different approach: building an environment that will allow you to be more productive in the new year, using tools you may or may not already be using.
|
||||
|
||||
### Track your tasks with todo
|
||||
|
||||
Tasks and to-do lists are very near and dear to my heart. I'm a big fan of productivity (so much so that I do a [podcast][2] about it) and try all sorts of different applications. I've even [given presentations][3] and [written articles][4] about them. So it only makes sense that, when I talk about being productive, task and to-do list tools are certain to come up.
|
||||
|
||||
![Getting fancy with Todo.txt][5]
|
||||
|
||||
In all honesty, for being simple, cross-platform, and easily synchronized, you cannot go wrong with [todo.txt][6]. It is one of the two to-do list and task management apps that I keep coming back to over and over again (the other is [Org mode][7]). And what keeps me coming back is that it is simple, portable, understandable, and has many great add-ons that don't break it if one machine has them and the others don't. And since it is a Bash shell script, I have never found a system that cannot support it.
|
||||
|
||||
#### Set up todo.txt
|
||||
|
||||
First things first, you need to install the base shell script and copy the default configuration file to the **~/.todo** directory:
|
||||
|
||||
|
||||
```
|
||||
git clone <https://github.com/todotxt/todo.txt-cli.git>
|
||||
cd todo.txt-cli
|
||||
make
|
||||
sudo make install
|
||||
mkdir ~/.todo
|
||||
cp todo.cfg ~/.todo/config
|
||||
```
|
||||
|
||||
Next, set up the configuration file. I like to uncomment the color settings at this point, but the only thing that must be set up right away is the **TODO_DIR** variable:
|
||||
|
||||
|
||||
```
|
||||
`export TODO_DIR="$HOME/.todo"`
|
||||
```
|
||||
|
||||
#### Add to-do's
|
||||
|
||||
To add your first to-do item, simply type **todo.sh add <NewTodo>**, and it will be added. This will also create three files in **$HOME/.todo/**: todo.txt, done.txt, and reports.txt.
|
||||
|
||||
After adding a few items, run **todo.sh ls** to see your to-do list.
|
||||
|
||||
![Basic todo.txt list][8]
|
||||
|
||||
#### Manage your tasks
|
||||
|
||||
You can improve it a little by prioritizing the items. To add a priority to an item, run **todo.sh pri # A**. The number is the number of the task on the list, and the letter "A" is the priority. You can set the priority as anything from A to Z since that's how it will get sorted.
|
||||
|
||||
To complete a task, run **todo.sh do #** to mark the item done and move the item to done.txt. Running **todo.sh report** will write a count of done and not done items to reports.txt.
|
||||
|
||||
The file format used for all three files is well documented, so you can make changes with your text editor of choice. The basic format of todo.txt is:
|
||||
|
||||
|
||||
```
|
||||
`(Priority) YYYY-MM-DD Task`
|
||||
```
|
||||
|
||||
The date indicates the due date of a task, if one is set. When editing the file manually, just put an "x" in front of the task to mark it as done. Running **todo.sh archive** will move these items to done.txt, and you can work in that text file and archive the done items when you have time.
|
||||
|
||||
#### Set up recurring tasks
|
||||
|
||||
I have a lot of recurring tasks that I need to schedule every day/week/month.
|
||||
|
||||
![Recurring tasks with the ice_recur add-on][9]
|
||||
|
||||
This is where todo.txt's flexibility comes in. By using [add-ons][10] in **~/.todo.actions.d/**, you can add commands and extend the functionality of the base todo.sh. The add-ons are basically scripts that implement specific commands. For recurring tasks, the plugin [ice_recur][11] should fit the bill. By following the instructions on the page, you can set up tasks to recur in a very flexible manner.
|
||||
|
||||
![Todour on MacOS][12]
|
||||
|
||||
There are a lot of add-ons in the directory, including syncing to some cloud services. There are also links to desktop and mobile apps, so you can keep your to-do list with you on the go.
|
||||
|
||||
I've only scratched the surface of todo's functionality, so take some time to dig in and see how powerful this tool is! It really helps me keep on task every day.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/1/open-source-to-do-list
|
||||
|
||||
作者：[Kevin Sonney][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/ksonney
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/checklist_todo_clock_time_team.png?itok=1z528Q0y (Team checklist)
|
||||
[2]: https://productivityalchemy.com/
|
||||
[3]: https://www.slideshare.net/AllThingsOpen/getting-to-done-on-the-command-line
|
||||
[4]: https://opensource.com/article/18/2/getting-to-done-agile-linux-command-line
|
||||
[5]: https://opensource.com/sites/default/files/uploads/productivity_7-1.png
|
||||
[6]: http://todotxt.org/
|
||||
[7]: https://orgmode.org/
|
||||
[8]: https://opensource.com/sites/default/files/uploads/productivity_7-2.png (Basic todo.txt list)
|
||||
[9]: https://opensource.com/sites/default/files/uploads/productivity_7-3.png (Recurring tasks with the ice_recur add-on)
|
||||
[10]: https://github.com/todotxt/todo.txt-cli/wiki/Todo.sh-Add-on-Directory
|
||||
[11]: https://github.com/rlpowell/todo-text-stuff
|
||||
[12]: https://opensource.com/sites/default/files/uploads/productivity_7-4.png (Todour on MacOS)
|
||||
@ -0,0 +1,768 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (Use Wireshark at the Linux command line with TShark)
|
||||
[#]: via: (https://opensource.com/article/20/1/wireshark-linux-tshark)
|
||||
[#]: author: (Gaurav Kamathe https://opensource.com/users/gkamathe)
|
||||
|
||||
Use Wireshark at the Linux command line with TShark
|
||||
======
|
||||
Learning to analyze network packets is a powerful skill.
|
||||
![Multi-colored and directional network computer cables][1]
|
||||
|
||||
Most of the time when we connect to the internet, we don't think about the network protocols at work underneath that make it all possible. Right now, while you are reading this article, numerous packets are being exchanged by your computer and traveling across the internet.
|
||||
|
||||
To understand these protocols, you need a tool that can capture and help you analyze these packets. [Wireshark][2] is a popular open source graphical user interface (GUI) tool for analyzing packets. However, it also provides a powerful command-line utility called [TShark][3] for people who prefer to work on the Linux command line.
|
||||
|
||||
To try the examples in this article, you need to be connected to the internet. For any changes to TShark's command-line options or flags, please refer to the appropriate man pages and online [documentation][4]. Also, I am using Fedora for these examples.
|
||||
|
||||
|
||||
```
|
||||
[gaurav@testbox ~]$ cat /etc/fedora-release
|
||||
Fedora release 30 (Thirty)
|
||||
[gaurav@testbox ~]$
|
||||
```
|
||||
|
||||
### Check your installation
|
||||
|
||||
First, ensure the required packages are installed:
|
||||
|
||||
|
||||
```
|
||||
[gaurav@testbox ~]$ rpm -qa | grep -i wireshark
|
||||
wireshark-cli-3.0.1-1.fc30.x86_64
|
||||
[gaurav@testbox ~]$
|
||||
```
|
||||
|
||||
If the Wireshark package is installed, check whether the TShark utility is installed and, if so, which version:
|
||||
|
||||
|
||||
```
|
||||
[gaurav@testbox ~]$ tshark -v
|
||||
TShark (Wireshark) 3.0.1 (23f278e2)
|
||||
|
||||
Built using gcc 9.0.1 20190312 (Red Hat 9.0.1-0.10).
|
||||
[gaurav@testbox ~]$
|
||||
```
|
||||
|
||||
If you are logged in as a regular, non-root user, you need sudo rights to use the TShark utility. Root users can skip sudo and directly run the **tshark** command.
|
||||
|
||||
### Find network devices available to TShark
|
||||
|
||||
Before TShark can analyze packets, it needs to capture those packets. Network packets are processed via a network interface card (NIC) on servers, workstations, or desktops or a WiFi card on laptops. Begin by identifying the NIC or WiFi card used to connect to the internet.
|
||||
|
||||
To identify what network devices are available to TShark, run the following command. My laptop (which I am using for these examples) shows:
|
||||
|
||||
|
||||
```
|
||||
[gaurav@testbox ~]$ sudo tshark -D
|
||||
Running as user "root" and group "root". This could be dangerous.
|
||||
1\. wlp61s0
|
||||
2\. lo (Loopback)
|
||||
3\. any
|
||||
4\. virbr0
|
||||
5\. enp0s31f6
|
||||
6\. bluetooth-monitor
|
||||
7\. nflog
|
||||
8\. nfqueue
|
||||
[gaurav@testbox ~]$
|
||||
```
|
||||
|
||||
I am using my WiFi card to connect to my home router for accessing the internet. You can use the **ifconfig -a** command to view all network interfaces on a system. If the **ifconfig** command is not installed, you can use the newer **ip addr show** command instead. One of the interfaces should have an IP address assigned to it. For a specific interface, you can use **ifconfig <interface-name>**, for example:
|
||||
|
||||
|
||||
```
|
||||
`ifconfig wlp61s0`
|
||||
```
|
||||
|
||||
### Capture some packets
|
||||
|
||||
Now that you know which interface is being used to connect to the internet, you can start capturing some packets using it. The **-i** option can be used to capture packets on this specific interface. You'll see a bunch of output that shows the network packets being transmitted via the interface, but you can stop it with the **Ctrl+C** command:
|
||||
|
||||
|
||||
```
|
||||
[gaurav@testbox ~]$ sudo tshark -i wlp61s0
|
||||
Running as user "root" and group "root". This could be dangerous.
|
||||
Capturing on 'wlp61s0'
|
||||
1 0.000000000 192.168.1.9 → 192.168.1.1 DNS 77 Standard query 0xa02b AAAA fedoraproject.org
|
||||
2 0.000128115 192.168.1.9 → 192.168.1.1 DNS 77 Standard query 0xcc47 A fedoraproject.org
|
||||
3 0.000316195 192.168.1.9 → 192.168.1.1 DNS 77 Standard query 0xe29d A fedoraproject.org
|
||||
4 0.000616019 192.168.1.9 → 192.168.1.1 DNS 77 Standard query 0xac7c AAAA fedoraproject.org
|
||||
5 0.007963200 192.168.1.1 → 192.168.1.9 DNS 93 Standard query response 0xcc47 A fedoraproject.org A 185.141.165.254
|
||||
6 0.009171815 192.168.1.1 → 192.168.1.9 DNS 93 Standard query response 0xe29d A fedoraproject.org A 185.141.165.254
|
||||
7 0.011075350 192.168.1.1 → 192.168.1.9 DNS 322 Standard query response 0xa02b AAAA fedoraproject.org AAAA 2610:28:3090:3001:dead:beef:cafe:fed3 AAAA 2605:bc80:3010:600:dead:beef:cafe:fed9 AAAA 2604:1580:fe00:0:dead:beef:cafe:fed1 NS ns04.fedoraproject.org NS ns05.fedoraproject.org NS ns02.fedoraproject.org A 152.19.134.139 AAAA 2610:28:3090:3001:dead:beef:cafe:fed5 A 209.132.181.17 A 85.236.55.10 AAAA 2001:4178:2:1269:dead:beef:cafe:fed5
|
||||
8 0.012458151 192.168.1.1 → 192.168.1.9 DNS 322 Standard query response 0xac7c AAAA fedoraproject.org AAAA 2605:bc80:3010:600:dead:beef:cafe:fed9 AAAA 2610:28:3090:3001:dead:beef:cafe:fed3 AAAA 2604:1580:fe00:0:dead:beef:cafe:fed1 NS ns05.fedoraproject.org NS ns02.fedoraproject.org NS ns04.fedoraproject.org A 152.19.134.139 AAAA 2610:28:3090:3001:dead:beef:cafe:fed5 A 209.132.181.17 A 85.236.55.10 AAAA 2001:4178:2:1269:dead:beef:cafe:fed5
|
||||
^C8 packets captured
|
||||
[gaurav@testbox ~]$
|
||||
```
|
||||
|
||||
Look at the first two packets above; they are denoted by numbers at the beginning of the line:
|
||||
|
||||
|
||||
```
|
||||
1 0.000000000 192.168.1.9 → 192.168.1.1 DNS 77 Standard query 0xa02b AAAA fedoraproject.org
|
||||
2 0.000128115 192.168.1.9 → 192.168.1.1 DNS 77 Standard query 0xcc47 A fedoraproject.org
|
||||
```
|
||||
|
||||
These lines include two IP addresses on either side of an arrow—these are the hosts that are exchanging the packet. The arrow's direction indicates which direction the packet is going. Therefore, **192.168.1.9 → 192.168.1.1** means the packet originated at host **192.168.1.9**, which is my laptop, and is headed for destination **192.168.1.1**, which is my home router. After the destination IP address, you see **DNS**, which is just the Domain Name System protocol, followed by a DNS query. More about that later.
|
||||
|
||||
You can limit the number of packets captured and displayed on the screen using the **-c** (count) option. The following example shows 10 packets being captured. Notice the protocols—you saw DNS above, and here there are other protocols like NTP and TCP:
|
||||
|
||||
|
||||
```
|
||||
[gaurav@testbox ~]$ sudo tshark -i wlp61s0 -c 10
|
||||
Running as user "root" and group "root". This could be dangerous.
|
||||
Capturing on 'wlp61s0'
|
||||
1 0.000000000 192.168.1.9 → 10.5.26.10 NTP 90 NTP Version 4, client
|
||||
2 0.803303963 192.168.1.9 → 10.5.27.10 NTP 90 NTP Version 4, client
|
||||
3 3.524867645 192.168.1.9 → 192.168.1.1 DNS 69 Standard query 0x3837 A testbox
|
||||
4 6.227373094 192.168.1.9 → 192.168.1.1 DNS 89 Standard query 0x0814 A location.services.mozilla.com
|
||||
5 6.227395145 192.168.1.9 → 192.168.1.1 DNS 89 Standard query 0x5e1c AAAA location.services.mozilla.com
|
||||
6 6.234878912 192.168.1.1 → 192.168.1.9 DNS 105 Standard query response 0x0814 A location.services.mozilla.com A 34.253.23.107
|
||||
7 6.238110416 192.168.1.1 → 192.168.1.9 DNS 223 Standard query response 0x5e1c AAAA location.services.mozilla.com CNAME locprod1-elb-eu-west-1.prod.mozaws.net SOA ns-1260.awsdns-29.org
|
||||
8 6.238446999 192.168.1.9 → 34.253.23.107 TCP 74 35326 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=2832002333 TSecr=0 WS=128
|
||||
9 6.438833991 34.253.23.107 → 192.168.1.9 TCP 74 443 → 35326 [SYN, ACK] Seq=0 Ack=1 Win=26847 Len=0 MSS=1440 SACK_PERM=1 TSval=2056252981 TSecr=2832002333 WS=256
|
||||
10 6.438947001 192.168.1.9 → 34.253.23.107 TCP 66 35326 → 443 [ACK] Seq=1 Ack=1 Win=64256 Len=0 TSval=2832002533 TSecr=2056252981
|
||||
10 packets captured
|
||||
[gaurav@testbox ~]$
|
||||
```
|
||||
|
||||
The DNS protocol converts the hostname to an IP address and the IP address to a hostname. There are dedicated DNS (or name) servers, which you can query with either a hostname or an IP address. The example below uses the **nslookup** command to query the name servers to resolve a hostname to an IP address. Before you proceed, ensure the **bind-utils** package is installed:
|
||||
|
||||
|
||||
```
|
||||
[gaurav@testbox ~]$ rpm -qa | grep -i bind-utils
|
||||
bind-utils-9.11.5-13.P4.fc30.x86_64
|
||||
[gaurav@testbox ~]$
|
||||
```
|
||||
|
||||
In order to query your name server, you need to find out which one your machine is talking to. You can find that information in the **/etc/resolv.conf** file. In my case, the name server is pointed to **1.1.1.1**, which is a public DNS service provided by Cloudflare:
|
||||
|
||||
|
||||
```
|
||||
[gaurav@testbox ~]$ cat /etc/resolv.conf
|
||||
# Generated by NetworkManager
|
||||
nameserver 1.1.1.1
|
||||
[gaurav@testbox ~]$
|
||||
```
|
||||
|
||||
Hostnames like Opensource.com are easy for humans to understand, but machines use IP addresses to connect to other machines over a network or the internet. For your computer to connect to opensource.com, it needs to find the site's IP address; you can find it with the command:
|
||||
|
||||
|
||||
```
|
||||
`nslookup opensource.com`
|
||||
```
|
||||
|
||||
If **nslookup** is not available on your machine, you can use the **dig** command instead:
|
||||
|
||||
|
||||
```
|
||||
`dig opensource.com`
|
||||
```
|
||||
|
||||
But—_before you hit Enter_—open another terminal and type the following command to tell TShark to capture any traffic that goes to your name server (e.g., 1.1.1.1):
|
||||
|
||||
|
||||
```
|
||||
`sudo tshark -i wlp61s0 host 1.1.1.1`
|
||||
```
|
||||
|
||||
Keep that terminal running and return to the other one, then run **nslookup** (or **dig**). When the command completes, it gives Opensource.com's IP address, which is 54.204.39.132. Here is **nslookup**'s output:
|
||||
|
||||
|
||||
```
|
||||
[gaurav@testbox ~]$ nslookup opensource.com
|
||||
Server: 1.1.1.1
|
||||
Address: 1.1.1.1#53
|
||||
|
||||
Non-authoritative answer:
|
||||
Name: opensource.com
|
||||
Address: 54.204.39.132
|
||||
|
||||
[gaurav@testbox ~]$
|
||||
```
|
||||
|
||||
And **dig**'s output:
|
||||
|
||||
|
||||
```
|
||||
[gaurav@testbox ~]$ dig opensource.com
|
||||
|
||||
; <<>> DiG 9.11.5-P4-RedHat-9.11.5-13.P4.fc30 <<>> opensource.com
|
||||
;; global options: +cmd
|
||||
;; Got answer:
|
||||
;; ->>HEADER<<\- opcode: QUERY, status: NOERROR, id: 33030
|
||||
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
|
||||
|
||||
;; OPT PSEUDOSECTION:
|
||||
; EDNS: version: 0, flags:; udp: 1452
|
||||
;; QUESTION SECTION:
|
||||
;opensource.com. IN A
|
||||
|
||||
;; ANSWER SECTION:
|
||||
opensource.com. 206 IN A 54.204.39.132
|
||||
|
||||
;; Query time: 30 msec
|
||||
;; SERVER: 1.1.1.1#53(1.1.1.1)
|
||||
;; WHEN: Sat Nov 02 21:05:54 IST 2019
|
||||
;; MSG SIZE rcvd: 59
|
||||
|
||||
[gaurav@testbox ~]$
|
||||
```
|
||||
|
||||
So far, so good, but what is happening at the packet level? Move to the terminal where you entered the **tshark** command. It captured a few packets:
|
||||
|
||||
|
||||
```
|
||||
[gaurav@testbox ~]$ sudo tshark -i wlp61s0 host 1.1.1.1
|
||||
Running as user "root" and group "root". This could be dangerous.
|
||||
Capturing on 'wlp61s0'
|
||||
2 1.798275687 192.168.1.9 → 1.1.1.1 DNS 74 Standard query 0xcda0 A opensource.com
|
||||
3 1.827143443 1.1.1.1 → 192.168.1.9 DNS 90 Standard query response 0xcda0 A opensource.com A 54.204.39.132
|
||||
^C packets captured
|
||||
[gaurav@testbox ~]$
|
||||
```
|
||||
|
||||
The packet below originated from my laptop **192.168.1.9** and is headed for destination **1.1.1.1**. The packet is for the DNS protocol, and it's querying (Standard query) the name server for Opensource.com:
|
||||
|
||||
|
||||
```
|
||||
`2 1.798275687 192.168.1.9 → 1.1.1.1 DNS 74 Standard query 0xcda0 A opensource.com`
|
||||
```
|
||||
|
||||
The packet below is a reply coming from my name server **1.1.1.1** to my machine **192.168.1.9**. Again, it's DNS, but now it's a response for the query (Standard query response) for Opensource.com's IP address:
|
||||
|
||||
|
||||
```
|
||||
`3 1.827143443 1.1.1.1 → 192.168.1.9 DNS 90 Standard query response 0xcda0 A opensource.com A 54.204.39.132`
|
||||
```
|
||||
|
||||
If you know beforehand what protocol you are looking for, you can add it to the **tshark** command. The following example is looking only for UDP packets, but it captured DNS packets. This is because DNS packets use the UDP protocol underneath:
|
||||
|
||||
|
||||
```
|
||||
[gaurav@testbox ~]$ sudo tshark -i wlp61s0 udp
|
||||
Running as user "root" and group "root". This could be dangerous.
|
||||
Capturing on 'wlp61s0'
|
||||
1 0.000000000 192.168.1.9 → 1.1.1.1 DNS 89 Standard query 0xcc6d A location.services.mozilla.com
|
||||
2 0.000068640 192.168.1.9 → 1.1.1.1 DNS 89 Standard query 0x6484 AAAA location.services.mozilla.com
|
||||
3 0.032616053 1.1.1.1 → 192.168.1.9 DNS 189 Standard query response 0xcc6d A location.services.mozilla.com CNAME locprod1-elb-eu-west-1.prod.mozaws.net A 52.215.71.87 A 54.72.168.141 A 34.253.23.107
|
||||
4 0.108203529 1.1.1.1 → 192.168.1.9 DNS 241 Standard query response 0x6484 AAAA location.services.mozilla.com CNAME locprod1-elb-eu-west-1.prod.mozaws.net SOA ns-1260.awsdns-29.org
|
||||
5 1.268489014 192.168.1.9 → 1.1.1.1 DNS 69 Standard query 0x74be A testbox
|
||||
6 1.302652455 1.1.1.1 → 192.168.1.9 DNS 144 Standard query response 0x74be No such name A testbox SOA a.root-servers.net
|
||||
7 6.268558254 192.168.1.9 → 1.1.1.1 DNS 79 Standard query 0xc47a A cups.pnq.redhat.com
|
||||
8 6.268618039 192.168.1.9 → 1.1.1.1 DNS 79 Standard query 0xb08b AAAA cups.pnq.redhat.com
|
||||
9 6.664992312 1.1.1.1 → 192.168.1.9 DNS 143 Standard query response 0xb08b AAAA cups.pnq.redhat.com SOA a1-68.akam.net
|
||||
10 6.665088305 1.1.1.1 → 192.168.1.9 DNS 143 Standard query response 0xc47a A cups.pnq.redhat.com SOA a1-68.akam.net
|
||||
^C10 packets captured
|
||||
[gaurav@testbox ~]$
|
||||
```
|
||||
|
||||
The **ping** command is often used to check if a machine is up or accessible over a network. You can run the **ping** command against Opensource.com's IP address to see if the server is up and running.
|
||||
|
||||
Before you do that, start a packet capture so you can analyze the packet later. Open a terminal and run the following command, which will keep running and looking for packets that are originating in or destined for IP address 54.204.39.132:
|
||||
|
||||
|
||||
```
|
||||
`sudo tshark -i wlp61s0 host 54.204.39.132`
|
||||
```
|
||||
|
||||
In another terminal, run the following **ping** command. The **-c** is for count, so **-c 2** means it should send only two packets to the given host:
|
||||
|
||||
|
||||
```
|
||||
`ping -c 2 54.204.39.132`
|
||||
```
|
||||
|
||||
From the terminal where you ran the **ping** command, you can see two packets were sent and two were received. It also says that there was 0% packet loss, which suggests that the destination 54.204.39.132 responded to the **ping** requests:
|
||||
|
||||
|
||||
```
|
||||
[gaurav@testbox ~]$ ping -c 2 54.204.39.132
|
||||
PING 54.204.39.132 (54.204.39.132) 56(84) bytes of data.
|
||||
64 bytes from 54.204.39.132: icmp_seq=1 ttl=43 time=357 ms
|
||||
64 bytes from 54.204.39.132: icmp_seq=2 ttl=43 time=278 ms
|
||||
|
||||
\--- 54.204.39.132 ping statistics ---
|
||||
2 packets transmitted, 2 received, 0% packet loss, time 1ms
|
||||
rtt min/avg/max/mdev = 278.045/317.410/356.776/39.369 ms
|
||||
[gaurav@testbox ~]$
|
||||
```
|
||||
|
||||
Move back to the terminal where TShark is running. It shows four packets: the requests in the **ping** command (**-c 2**) and two replies, hence a total of four packets:
|
||||
|
||||
|
||||
```
|
||||
Packet 1 - request (1st request)
|
||||
Packet 2 - reply (to Packet 1)
|
||||
Packet 3 - request (2nd request)
|
||||
Packet 4 - reply (to Packet 3)
|
||||
```
|
||||
|
||||
The output shows that it is using the [ICMP][5] protocol. **Ping** works over ICMP to complete its tasks:
|
||||
|
||||
|
||||
```
|
||||
[gaurav@testbox ~]$ sudo tshark -i wlp61s0 host 54.204.39.132
|
||||
Running as user "root" and group "root". This could be dangerous.
|
||||
Capturing on 'wlp61s0'
|
||||
1 0.000000000 192.168.1.9 → 54.204.39.132 ICMP 98 Echo (ping) request id=0x1749, seq=1/256, ttl=64
|
||||
2 0.356750411 54.204.39.132 → 192.168.1.9 ICMP 98 Echo (ping) reply id=0x1749, seq=1/256, ttl=43 (request in 1)
|
||||
3 1.000295229 192.168.1.9 → 54.204.39.132 ICMP 98 Echo (ping) request id=0x1749, seq=2/512, ttl=64
|
||||
4 1.278267790 54.204.39.132 → 192.168.1.9 ICMP 98 Echo (ping) reply id=0x1749, seq=2/512, ttl=43 (request in 3)
|
||||
^C4 packets captured
|
||||
[gaurav@testbox ~]$
|
||||
```
|
||||
|
||||
Network packets are sent in binary format, so if you want to see how they look on the network, you can dump the packet's hexadecimal format by simply adding an **-x** to the **tshark** command, and you will see the hexadecimal output. The following output shows a **ping** request sent by running the command **ping -c 1 54.204.39.132**:
|
||||
|
||||
|
||||
```
|
||||
[gaurav@testbox ~]$ sudo tshark -i wlp61s0 -x -c 2 host 54.204.39.132
|
||||
Running as user "root" and group "root". This could be dangerous.
|
||||
Capturing on 'wlp61s0'
|
||||
0000 28 c6 8e 3e 39 3a 48 89 e7 a0 33 db 08 00 45 00 (..>9:H...3...E.
|
||||
0010 00 54 e6 29 40 00 40 01 34 7e c0 a8 01 09 36 cc .T.)@.@.4~....6.
|
||||
0020 27 84 08 00 25 5f 27 d1 00 01 7e aa bd 5d 00 00 '...%_'...~..]..
|
||||
0030 00 00 a2 f3 0d 00 00 00 00 00 10 11 12 13 14 15 ................
|
||||
0040 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 .......... !"#$%
|
||||
0050 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 &'()*+,-./012345
|
||||
0060 36 37 67
|
||||
|
||||
0000 48 89 e7 a0 33 db 28 c6 8e 3e 39 3a 08 00 45 00 H...3.(..>9:..E.
|
||||
0010 00 54 31 06 00 00 2b 01 3e a2 36 cc 27 84 c0 a8 .T1...+.>.6.'...
|
||||
0020 01 09 00 00 2d 5f 27 d1 00 01 7e aa bd 5d 00 00 ....-_'...~..]..
|
||||
0030 00 00 a2 f3 0d 00 00 00 00 00 10 11 12 13 14 15 ................
|
||||
0040 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 .......... !"#$%
|
||||
0050 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 &'()*+,-./012345
|
||||
0060 36 37 67
|
||||
|
||||
2 packets captured
|
||||
[gaurav@testbox ~]$
|
||||
```
|
||||
|
||||
### Save your output
|
||||
|
||||
Seeing output on the screen is OK, but often you need to save data to a file to use it later. Use the **ping** command but add **-w** to tell TShark to dump the output to a file. For example, the following saves the output to file named **nlog.pcap** within the **/tmp** directory:
|
||||
|
||||
|
||||
```
|
||||
`sudo tshark -w /tmp/nlog.pcap -i wlp61s0 host 54.204.39.132`
|
||||
```
|
||||
|
||||
Now run the **ping** command again from another terminal, but this time with a count of five packets:
|
||||
|
||||
|
||||
```
|
||||
`ping -c 5 54.204.39.132`
|
||||
```
|
||||
|
||||
The TShark terminal shows that 10 packets were captured. Why 10? Because you asked **ping** to send five requests, and you got five replies, hence 10 packets. Use **Ctrl+C** to stop the packet capture:
|
||||
|
||||
|
||||
```
|
||||
[gaurav@testbox ~]$ sudo tshark -w /tmp/nlog.pcap -i wlp61s0 host 54.204.39.132
|
||||
Running as user "root" and group "root". This could be dangerous.
|
||||
Capturing on 'wlp61s0'
|
||||
10 ^C
|
||||
[gaurav@testbox ~]$
|
||||
```
|
||||
|
||||
TShark saved the output to the file **/tmp/nlog.pcap**:
|
||||
|
||||
|
||||
```
|
||||
[gaurav@testbox ~]$ ls -l /tmp/nlog.pcap
|
||||
-rw-------. 1 root root 1692 Nov 2 21:10 /tmp/nlog.pcap
|
||||
[gaurav@testbox ~]$
|
||||
```
|
||||
|
||||
The **file** command shows the file type is a **pcapng** capture file, so you can't just open the file using an editor like Vim and start reading; all you'll see is a bunch of garbage characters:
|
||||
|
||||
|
||||
```
|
||||
[gaurav@testbox ~]$ sudo file /tmp/nlog.pcap
|
||||
/tmp/nlog.pcap: pcapng capture file - version 1.0
|
||||
[gaurav@testbox ~]$
|
||||
```
|
||||
|
||||
Since TShark wrote the data to the file, it can read it back from the file as well using the **-r** option followed by the filename. The following shows all 10 packets (five requests and five replies):
|
||||
|
||||
|
||||
```
|
||||
[gaurav@testbox ~]$ sudo tshark -r /tmp/nlog.pcap
|
||||
Running as user "root" and group "root". This could be dangerous.
|
||||
1 0.000000000 192.168.1.9 → 54.204.39.132 ICMP 98 Echo (ping) request id=0x1875, seq=1/256, ttl=64
|
||||
2 0.270098703 54.204.39.132 → 192.168.1.9 ICMP 98 Echo (ping) reply id=0x1875, seq=1/256, ttl=43 (request in 1)
|
||||
3 1.000485186 192.168.1.9 → 54.204.39.132 ICMP 98 Echo (ping) request id=0x1875, seq=2/512, ttl=64
|
||||
4 1.323571769 54.204.39.132 → 192.168.1.9 ICMP 98 Echo (ping) reply id=0x1875, seq=2/512, ttl=43 (request in 3)
|
||||
5 2.000955585 192.168.1.9 → 54.204.39.132 ICMP 98 Echo (ping) request id=0x1875, seq=3/768, ttl=64
|
||||
6 2.347737132 54.204.39.132 → 192.168.1.9 ICMP 98 Echo (ping) reply id=0x1875, seq=3/768, ttl=43 (request in 5)
|
||||
7 3.000912998 192.168.1.9 → 54.204.39.132 ICMP 98 Echo (ping) request id=0x1875, seq=4/1024, ttl=64
|
||||
8 3.269412434 54.204.39.132 → 192.168.1.9 ICMP 98 Echo (ping) reply id=0x1875, seq=4/1024, ttl=43 (request in 7)
|
||||
9 4.001573635 192.168.1.9 → 54.204.39.132 ICMP 98 Echo (ping) request id=0x1875, seq=5/1280, ttl=64
|
||||
10 4.293431592 54.204.39.132 → 192.168.1.9 ICMP 98 Echo (ping) reply id=0x1875, seq=5/1280, ttl=43 (request in 9)
|
||||
[gaurav@testbox ~]$
|
||||
|
||||
#TCP handshake
|
||||
```
|
||||
|
||||
A [TCP handshake][6] is done before establishing a connection over a network. The examples above just queried a name server or tried to determine whether a machine is reachable via a **ping** command, neither of which requires establishing a connection with the host. Try to fetch [www.opensource.com][7] via the **wget** command.
|
||||
|
||||
Before you run **wget**, run the following command in another terminal to capture packets. I have deliberately kept the count to three since the handshake involves initial packets:
|
||||
|
||||
|
||||
```
|
||||
`sudo tshark -i wlp61s0 -c 3 host 54.204.39.132`
|
||||
```
|
||||
|
||||
Next, run the **wget** command to download the index file:
|
||||
|
||||
|
||||
```
|
||||
[gaurav@testbox ~]$ wget <https://www.opensource.com>
|
||||
\--2019-11-02 21:13:54-- <https://www.opensource.com/>
|
||||
Resolving [www.opensource.com][7] ([www.opensource.com][7])... 54.204.39.132
|
||||
Connecting to [www.opensource.com][7] ([www.opensource.com)|54.204.39.132|:443][8]... connected.
|
||||
HTTP request sent, awaiting response... 301 Moved Permanently
|
||||
Location: <http://opensource.com/> [following]
|
||||
\--2019-11-02 21:13:56-- <http://opensource.com/>
|
||||
Resolving opensource.com (opensource.com)... 54.204.39.132
|
||||
Connecting to opensource.com (opensource.com)|54.204.39.132|:80... connected.
|
||||
HTTP request sent, awaiting response... 302 Found
|
||||
Location: <https://opensource.com/> [following]
|
||||
\--2019-11-02 21:13:57-- <https://opensource.com/>
|
||||
Connecting to opensource.com (opensource.com)|54.204.39.132|:443... connected.
|
||||
HTTP request sent, awaiting response... 200 OK
|
||||
Length: 71561 (70K) [text/html]
|
||||
Saving to: ‘index.html’
|
||||
|
||||
index.html 100%[=============================================================>] 69.88K 105KB/s in 0.7s
|
||||
|
||||
2019-11-02 21:13:59 (105 KB/s) - ‘index.html’ saved [71561/71561]
|
||||
|
||||
[gaurav@testbox ~]$ ^C
|
||||
```
|
||||
|
||||
You can view the three packets below. The first packet sends a **SYN** request from my laptop to the Opensource.com server. The second packet is the Opensource.com server replying with a **SYN, ACK** flag set. Finally, the third packet is my laptop sending an **ACK** request to acknowledge receiving the second packet. This is called a TCP handshake. After this handshake, both nodes (i.e., my laptop and the Opensource.com server) can exchange data.
|
||||
|
||||
|
||||
```
|
||||
[gaurav@testbox ~]$ sudo tshark -i wlp61s0 -c 3 host 54.204.39.132
|
||||
Running as user "root" and group "root". This could be dangerous.
|
||||
Capturing on 'wlp61s0'
|
||||
1 0.000000000 192.168.1.9 → 54.204.39.132 TCP 74 58784 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=790376430 TSecr=0 WS=128
|
||||
2 0.306538226 54.204.39.132 → 192.168.1.9 TCP 74 443 → 58784 [SYN, ACK] Seq=0 Ack=1 Win=26847 Len=0 MSS=1440 SACK_PERM=1 TSval=1306268046 TSecr=790376430 WS=512
|
||||
3 0.306671608 192.168.1.9 → 54.204.39.132 TCP 66 58784 → 443 [ACK] Seq=1 Ack=1 Win=64256 Len=0 TSval=790376737 TSecr=1306268046
|
||||
3 packets captured
|
||||
[gaurav@testbox ~]$
|
||||
```
|
||||
|
||||
If you exclude **-c 3**, it will capture all packets, and you will see a similar ritual to close a connection. Only this time, my laptop sent a **FIN, ACK** packet to Opensource.com (in packet 1 below), followed by a **FIN, ACK** from Opensource.com to my laptop (in packet 2 below), and finally an **ACK** packet sent by my laptop to the Opensource.com server. This concludes the network connection that was established earlier, and any future connections will have to set up a TCP handshake again.
|
||||
|
||||
|
||||
```
|
||||
73 4.505715716 192.168.1.9 → 54.204.39.132 TCP 66 59574 → 443 [FIN, ACK] Seq=814 Ack=76239 Win=69888 Len=0 TSval=792384514 TSecr=1306769989
|
||||
74 4.737227282 54.204.39.132 → 192.168.1.9 TCP 66 443 → 59574 [FIN, ACK] Seq=76239 Ack=815 Win=29184 Len=0 TSval=1306770066 TSecr=792384514
|
||||
75 4.737389399 192.168.1.9 → 54.204.39.132 TCP 66 59574 → 443 [ACK] Seq=815 Ack=76240 Win=69888 Len=0 TSval=792384745 TSecr=1306770066
|
||||
```
|
||||
|
||||
### Encrypt handshake data
|
||||
|
||||
These days, most websites are accessed over HTTPS instead of HTTP. This ensures the data passed between the two nodes is encrypted on the wire as it passes through the internet. To ensure data is encrypted, a [TLS handshake][9] method, which is similar to the TCP handshake, happens.
|
||||
|
||||
Fire another **wget** command, but this time it captures 11 packets from the beginning:
|
||||
|
||||
|
||||
```
|
||||
[gaurav@testbox ~]$ wget <https://www.opensource.com>
|
||||
\--2019-11-02 21:15:21-- <https://www.opensource.com/>
|
||||
Resolving [www.opensource.com][7] ([www.opensource.com][7])... 54.204.39.132
|
||||
Connecting to [www.opensource.com][7] ([www.opensource.com)|54.204.39.132|:443][8]... connected.
|
||||
HTTP request sent, awaiting response... 301 Moved Permanently
|
||||
Location: <http://opensource.com/> [following]
|
||||
\--2019-11-02 21:15:23-- <http://opensource.com/>
|
||||
Resolving opensource.com (opensource.com)... 54.204.39.132
|
||||
Connecting to opensource.com (opensource.com)|54.204.39.132|:80... connected.
|
||||
HTTP request sent, awaiting response... 302 Found
|
||||
Location: <https://opensource.com/> [following]
|
||||
\--2019-11-02 21:15:28-- <https://opensource.com/>
|
||||
Connecting to opensource.com (opensource.com)|54.204.39.132|:443... connected.
|
||||
HTTP request sent, awaiting response... 200 OK
|
||||
Length: 71561 (70K) [text/html]
|
||||
Saving to: ‘index.html’
|
||||
|
||||
index.html 100%[=============================================================>] 69.88K 114KB/s in 0.6s
|
||||
|
||||
2019-11-02 21:15:31 (114 KB/s) - ‘index.html’ saved [71561/71561]
|
||||
|
||||
[gaurav@testbox ~]$
|
||||
```
|
||||
|
||||
The TCP handshake concludes in the first three packets, and the fourth to the ninth have various packets that have TLS strings, which follow a similar handshake ritual to set up a secure, encrypted connection between the two hosts:
|
||||
|
||||
|
||||
```
|
||||
[gaurav@testbox ~]$ sudo tshark -i wlp61s0 -c 11 host 54.204.39.132
|
||||
Running as user "root" and group "root". This could be dangerous.
|
||||
Capturing on 'wlp61s0'
|
||||
1 0.000000000 192.168.1.9 → 54.204.39.132 TCP 74 58800 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=790462858 TSecr=0 WS=128
|
||||
2 0.305006506 54.204.39.132 → 192.168.1.9 TCP 74 443 → 58800 [SYN, ACK] Seq=0 Ack=1 Win=26847 Len=0 MSS=1440 SACK_PERM=1 TSval=1306289652 TSecr=790462858 WS=512
|
||||
3 0.305135180 192.168.1.9 → 54.204.39.132 TCP 66 58800 → 443 [ACK] Seq=1 Ack=1 Win=64256 Len=0 TSval=790463163 TSecr=1306289652
|
||||
4 0.308282152 192.168.1.9 → 54.204.39.132 TLSv1 583 Client Hello
|
||||
5 0.613210220 54.204.39.132 → 192.168.1.9 TCP 66 443 → 58800 [ACK] Seq=1 Ack=518 Win=28160 Len=0 TSval=1306289729 TSecr=790463166
|
||||
6 0.613298883 54.204.39.132 → 192.168.1.9 TLSv1.2 3139 Server Hello, Certificate, Server Key Exchange, Server Hello Done
|
||||
7 0.613356054 192.168.1.9 → 54.204.39.132 TCP 66 58800 → 443 [ACK] Seq=518 Ack=3074 Win=61184 Len=0 TSval=790463472 TSecr=1306289729
|
||||
8 0.617318607 192.168.1.9 → 54.204.39.132 TLSv1.2 192 Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
|
||||
9 0.919718195 54.204.39.132 → 192.168.1.9 TLSv1.2 324 New Session Ticket, Change Cipher Spec, Encrypted Handshake Message
|
||||
10 0.940858609 192.168.1.9 → 54.204.39.132 TLSv1.2 240 Application Data
|
||||
11 1.228530079 54.204.39.132 → 192.168.1.9 TLSv1.2 754 Application Data
|
||||
11 packets captured
|
||||
[gaurav@testbox ~]$
|
||||
```
|
||||
|
||||
Because HTTPS works on port 443 by default, you can use it as a filter in TShark to capture traffic going to that specific port:
|
||||
|
||||
|
||||
```
|
||||
`sudo tshark -i wlp61s0 host 54.204.39.132 and port 443`
|
||||
```
|
||||
|
||||
Timestamps are essential when you need to analyze packets offline to reconstruct events from the past, e.g., for debugging. Adding a **-t ad** flag to TShark will add timestamps to the beginning of each packet capture:
|
||||
|
||||
|
||||
```
|
||||
[gaurav@testbox ~]$ sudo tshark -n -i wlp61s0 -t ad
|
||||
Running as user "root" and group "root". This could be dangerous.
|
||||
Capturing on 'wlp61s0'
|
||||
1 2019-11-02 21:43:58.344158174 25:c9:8e:3f:38:3a → 48:89:e7:a0:33:db ARP 42 Who has 192.168.1.9? Tell 192.168.1.1
|
||||
2 2019-11-02 21:43:58.344194844 48:89:e7:a0:33:db → 25:c9:8e:3f:38:3a ARP 42 192.168.1.9 is at 48:89:e7:a0:33:db
|
||||
3 2019-11-02 21:44:00.223393961 192.168.1.9 → 1.1.1.1 DNS 79 Standard query 0x00fb A cups.pnq.redhat.com
|
||||
4 2019-11-02 21:44:00.223460961 192.168.1.9 → 1.1.1.1 DNS 79 Standard query 0x1814 AAAA cups.pnq.redhat.com
|
||||
5 2019-11-02 21:44:00.266325914 1.1.1.1 → 192.168.1.9 DNS 143 Standard query response 0x00fb A cups.pnq.redhat.com SOA a1-68.akam.net
|
||||
6 2019-11-02 21:44:00.269102767 1.1.1.1 → 192.168.1.9 DNS 143 Standard query response 0x1814 AAAA cups.pnq.redhat.com SOA a1-68.akam.net
|
||||
^C6 packets captured
|
||||
[gaurav@testbox ~]$
|
||||
```
|
||||
|
||||
### View an entire packet
|
||||
|
||||
So far, you have seen several examples of packets and ways to interpret them but not an entire packet. Here's how to use **ping** and the **nslookup** utility to dump an entire packet:
|
||||
|
||||
|
||||
```
|
||||
[gaurav@testbox ~]$ ping -c 1 54.204.39.132
|
||||
PING 54.204.39.132 (54.204.39.132) 56(84) bytes of data.
|
||||
64 bytes from 54.204.39.132: icmp_seq=1 ttl=43 time=357 ms
|
||||
|
||||
\--- 54.204.39.132 ping statistics ---
|
||||
1 packets transmitted, 1 received, 0% packet loss, time 0ms
|
||||
rtt min/avg/max/mdev = 356.961/356.961/356.961/0.000 ms
|
||||
[gaurav@testbox ~]$
|
||||
```
|
||||
|
||||
In another window, run the following command and then the **ping** command above. Notice the additional **-V** flag—it is used to dump the entire packet information on the screen. The output is divided into various sections, starting with Frames, then moving to Ethernet, then to Internet Protocol, and so on.
|
||||
|
||||
|
||||
```
|
||||
[gaurav@testbox ~]$ sudo tshark -i wlp61s0 -c 1 -V host 54.204.39.132
|
||||
Running as user "root" and group "root". This could be dangerous.
|
||||
Capturing on 'wlp61s0'
|
||||
Frame 1: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) on interface 0
|
||||
Interface id: 0 (wlp61s0)
|
||||
Interface name: wlp61s0
|
||||
Encapsulation type: Ethernet (1)
|
||||
Arrival Time: Nov 2, 2019 21:17:55.556150846 IST
|
||||
[Time shift for this packet: 0.000000000 seconds]
|
||||
Epoch Time: 1572709675.556150846 seconds
|
||||
[Time delta from previous captured frame: 0.000000000 seconds]
|
||||
[Time delta from previous displayed frame: 0.000000000 seconds]
|
||||
[Time since reference or first frame: 0.000000000 seconds]
|
||||
Frame Number: 1
|
||||
Frame Length: 98 bytes (784 bits)
|
||||
Capture Length: 98 bytes (784 bits)
|
||||
[Frame is marked: False]
|
||||
[Frame is ignored: False]
|
||||
[Protocols in frame: eth:ethertype:ip:icmp:data]
|
||||
Ethernet II, Src: IntelCor_a0:33:db (48:89:e7:a0:33:db), Dst: Netgear_3f:38:3a (25:c9:8e:3f:38:3a)
|
||||
Destination: Netgear_3f:38:3a (25:c9:8e:3f:38:3a)
|
||||
Address: Netgear_3f:38:3a (25:c9:8e:3f:38:3a)
|
||||
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
|
||||
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
|
||||
Source: IntelCor_a0:33:db (48:89:e7:a0:33:db)
|
||||
Address: IntelCor_a0:33:db (48:89:e7:a0:33:db)
|
||||
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
|
||||
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
|
||||
Type: IPv4 (0x0800)
|
||||
Internet Protocol Version 4, Src: 192.168.1.9, Dst: 54.204.39.132
|
||||
0100 .... = Version: 4
|
||||
.... 0101 = Header Length: 20 bytes (5)
|
||||
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
|
||||
0000 00.. = Differentiated Services Codepoint: Default (0)
|
||||
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
|
||||
Total Length: 84
|
||||
Identification: 0x8f68 (36712)
|
||||
Flags: 0x4000, Don't fragment
|
||||
0... .... .... .... = Reserved bit: Not set
|
||||
.1.. .... .... .... = Don't fragment: Set
|
||||
..0. .... .... .... = More fragments: Not set
|
||||
...0 0000 0000 0000 = Fragment offset: 0
|
||||
Time to live: 64
|
||||
Protocol: ICMP (1)
|
||||
Header checksum: 0x8b3f [validation disabled]
|
||||
[Header checksum status: Unverified]
|
||||
Source: 192.168.1.9
|
||||
Destination: 54.204.39.132
|
||||
Internet Control Message Protocol
|
||||
Type: 8 (Echo (ping) request)
|
||||
Code: 0
|
||||
Checksum: 0xcfc5 [correct]
|
||||
[Checksum Status: Good]
|
||||
Identifier (BE): 7399 (0x1ce7)
|
||||
Identifier (LE): 59164 (0xe71c)
|
||||
Sequence number (BE): 1 (0x0001)
|
||||
Sequence number (LE): 256 (0x0100)
|
||||
Timestamp from icmp data: Nov 2, 2019 21:17:55.000000000 IST
|
||||
[Timestamp from icmp data (relative): 0.556150846 seconds]
|
||||
Data (48 bytes)
|
||||
|
||||
0000 5b 7c 08 00 00 00 00 00 10 11 12 13 14 15 16 17 [|..............
|
||||
0010 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 ........ !"#$%&'
|
||||
0020 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 ()*+,-./01234567
|
||||
Data: 5b7c080000000000101112131415161718191a1b1c1d1e1f…
|
||||
[Length: 48]
|
||||
|
||||
1 packet captured
|
||||
[gaurav@testbox ~]
|
||||
```
|
||||
|
||||
Similarly, run the following **nslookup** command and, on the side, dump the entire packet via TShark:
|
||||
|
||||
|
||||
```
|
||||
[gaurav@testbox ~]$ nslookup opensource.com
|
||||
Server: 1.1.1.1
|
||||
Address: 1.1.1.1#53
|
||||
|
||||
Non-authoritative answer:
|
||||
Name: opensource.com
|
||||
Address: 54.204.39.132
|
||||
|
||||
[gaurav@testbox ~]$
|
||||
```
|
||||
|
||||
Here is how the packet looks when you do a DNS lookup—notice the UDP protocol is being used:
|
||||
|
||||
|
||||
```
|
||||
[gaurav@testbox ~]$ sudo tshark -i wlp61s0 -c 1 -V host 1.1.1.1
|
||||
Running as user "root" and group "root". This could be dangerous.
|
||||
Capturing on 'wlp61s0'
|
||||
Frame 1: 88 bytes on wire (704 bits), 88 bytes captured (704 bits) on interface 0
|
||||
Interface id: 0 (wlp61s0)
|
||||
Interface name: wlp61s0
|
||||
Encapsulation type: Ethernet (1)
|
||||
Arrival Time: Nov 2, 2019 21:19:32.161216715 IST
|
||||
[Time shift for this packet: 0.000000000 seconds]
|
||||
Epoch Time: 1572709772.161216715 seconds
|
||||
[Time delta from previous captured frame: 0.000000000 seconds]
|
||||
[Time delta from previous displayed frame: 0.000000000 seconds]
|
||||
[Time since reference or first frame: 0.000000000 seconds]
|
||||
Frame Number: 1
|
||||
Frame Length: 88 bytes (704 bits)
|
||||
Capture Length: 88 bytes (704 bits)
|
||||
[Frame is marked: False]
|
||||
[Frame is ignored: False]
|
||||
[Protocols in frame: eth:ethertype:ip:udp:dns]
|
||||
Ethernet II, Src: IntelCor_a0:33:db (48:89:e7:a0:33:db), Dst: Netgear_3f:38:3a (25:c9:8e:3f:38:3a)
|
||||
Destination: Netgear_3f:38:3a (25:c9:8e:3f:38:3a)
|
||||
Address: Netgear_3f:38:3a (25:c9:8e:3f:38:3a)
|
||||
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
|
||||
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
|
||||
Source: IntelCor_a0:33:db (48:89:e7:a0:33:db)
|
||||
Address: IntelCor_a0:33:db (48:89:e7:a0:33:db)
|
||||
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
|
||||
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
|
||||
Type: IPv4 (0x0800)
|
||||
Internet Protocol Version 4, Src: 192.168.1.9, Dst: 1.1.1.1
|
||||
0100 .... = Version: 4
|
||||
.... 0101 = Header Length: 20 bytes (5)
|
||||
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
|
||||
0000 00.. = Differentiated Services Codepoint: Default (0)
|
||||
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
|
||||
Total Length: 74
|
||||
Identification: 0x907d (36989)
|
||||
Flags: 0x4000, Don't fragment
|
||||
0... .... .... .... = Reserved bit: Not set
|
||||
.1.. .... .... .... = Don't fragment: Set
|
||||
..0. .... .... .... = More fragments: Not set
|
||||
...0 0000 0000 0000 = Fragment offset: 0
|
||||
Time to live: 64
|
||||
Protocol: UDP (17)
|
||||
Header checksum: 0xe672 [validation disabled]
|
||||
[Header checksum status: Unverified]
|
||||
Source: 192.168.1.9
|
||||
Destination: 1.1.1.1
|
||||
User Datagram Protocol, Src Port: 60656, Dst Port: 53
|
||||
Source Port: 60656
|
||||
Destination Port: 53
|
||||
Length: 54
|
||||
Checksum: 0x2fd2 [unverified]
|
||||
[Checksum Status: Unverified]
|
||||
[Stream index: 0]
|
||||
[Timestamps]
|
||||
[Time since first frame: 0.000000000 seconds]
|
||||
[Time since previous frame: 0.000000000 seconds]
|
||||
Domain Name System (query)
|
||||
Transaction ID: 0x303c
|
||||
Flags: 0x0100 Standard query
|
||||
0... .... .... .... = Response: Message is a query
|
||||
.000 0... .... .... = Opcode: Standard query (0)
|
||||
.... ..0. .... .... = Truncated: Message is not truncated
|
||||
.... ...1 .... .... = Recursion desired: Do query recursively
|
||||
.... .... .0.. .... = Z: reserved (0)
|
||||
.... .... ...0 .... = Non-authenticated data: Unacceptable
|
||||
Questions: 1
|
||||
Answer RRs: 0
|
||||
Authority RRs: 0
|
||||
Additional RRs: 0
|
||||
Queries
|
||||
clock01.util.phx2.redhat.com: type A, class IN
|
||||
Name: clock01.util.phx2.redhat.com
|
||||
[Name Length: 28]
|
||||
[Label Count: 5]
|
||||
Type: A (Host Address) (1)
|
||||
Class: IN (0x0001)
|
||||
|
||||
1 packet captured
|
||||
[gaurav@testbox ~]$
|
||||
```
|
||||
|
||||
### Next steps
|
||||
|
||||
Once you are comfortable with these basics of packet capturing and analysis, you can utilize TShark's various capture and display filters when working on more advanced use cases. Refer to the online documentation for more information on these filters.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/1/wireshark-linux-tshark
|
||||
|
||||
作者：[Gaurav Kamathe][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/gkamathe
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/connections_wires_sysadmin_cable.png?itok=d5WqHmnJ (Multi-colored and directional network computer cables)
|
||||
[2]: https://www.wireshark.org/
|
||||
[3]: https://www.wireshark.org/docs/wsug_html_chunked/AppToolstshark.html
|
||||
[4]: https://www.wireshark.org/docs/man-pages/tshark.html
|
||||
[5]: https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol
|
||||
[6]: https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_establishment
|
||||
[7]: http://www.opensource.com
|
||||
[8]: http://www.opensource.com)|54.204.39.132|:443
|
||||
[9]: https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake
|
||||
@ -1,5 +1,5 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
|
||||
@ -0,0 +1,107 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (Get started with this open source to-do list manager)
|
||||
[#]: via: (https://opensource.com/article/20/1/open-source-to-do-list)
|
||||
[#]: author: (Kevin Sonney https://opensource.com/users/ksonney)
|
||||
|
||||
开始使用开源待办清单管理器
|
||||
======
|
||||
Todo 是跟踪任务列表的强大方法。在我们的 20 个使用开源提升生产力的系列的第七篇文章中了解如何使用它。
|
||||
![Team checklist][1]
|
||||
|
||||
去年，我在 19 天里给你介绍了 19 个新（对你而言）的生产力工具。今年，我换了一种方式：使用你在使用或者还没使用的工具，构建一个使你可以在新一年更加高效的环境。
|
||||
|
||||
### 使用 todo 跟踪任务
|
||||
|
||||
任务和待办事项列表离我很近。我是生产力的狂热粉丝（以至于我为此做了一个[播客][2]），我尝试了各种不同的应用。我甚至为此[做了演讲][3]并[写了些文章][4]。因此，当我谈到提高工作效率时，肯定会出现任务和待办事项清单工具。
|
||||
|
||||
![Getting fancy with Todo.txt][5]
|
||||
|
||||
说实话，由于简单、跨平台且易于同步，你用 [todo.txt][6] 不会错。它是两个我经常使用的待办列表以及任务管理应用之一（另一个是 [Org mode][7]）。让我继续使用它的原因它简单、便携、易于理解，并且有许多很好的附加组件，并且当一台机器有附加组件，而另一台没有，也不会破坏程序。由于它是一个 Bash shell 脚本，我还没发现一个无法支持它的系统。
|
||||
|
||||
#### 设置 todo.txt
|
||||
|
||||
首先，你需要安装基本 shell 脚本并将默认配置文件复制到 **~/.todo** 目录：
|
||||
|
||||
|
||||
```
|
||||
git clone <https://github.com/todotxt/todo.txt-cli.git>
|
||||
cd todo.txt-cli
|
||||
make
|
||||
sudo make install
|
||||
mkdir ~/.todo
|
||||
cp todo.cfg ~/.todo/config
|
||||
```
|
||||
|
||||
接下来，设置配置文件。此时，我想取消注释颜色设置，但必须马上设置的是 **TODO_DIR** 变量：
|
||||
|
||||
|
||||
```
|
||||
`export TODO_DIR="$HOME/.todo"`
|
||||
```
|
||||
|
||||
#### 添加待办事件
|
||||
|
||||
要添加第一个待办事件，只需输入 **todo.sh add <NewTodo>** 就能添加。这还将在 **$HOME/.todo/** 中创建三个文件：todo.txt、todo.txt 和 reports.txt。
|
||||
|
||||
添加几个项目后，运行 **todo.sh ls** 查看你的待办事项。
|
||||
|
||||
![Basic todo.txt list][8]
|
||||
|
||||
#### 管理任务
|
||||
|
||||
你可以通过给项目设置优先级来稍微改善它。要向项目添加优先级，运行 **todo.sh pri # A**。数字是列表中任务的数量，而字母 ”A“ 是优先级。你可以将优先级设置为从 A 到 Z，因为这是它的排序方式。
|
||||
|
||||
要完成任务，运行**todo.sh do #** 来标记项目已完成，并将项目移动到 done.txt。运行 **todo.sh report** 会向 report.txt 写入已完成和未完成项的数量。
|
||||
|
||||
所有三个文件的格式都有详细记录，因此你可以选择自己的文本编辑器修改。todo.txt 的基本格式是：
|
||||
|
||||
|
||||
```
|
||||
`(Priority) YYYY-MM-DD Task`
|
||||
```
|
||||
|
||||
如果设置了任务，那么日期表示任务的到期日期。手动编辑文件时，只需在任务前面加一个 ”x“ 来标记为已完成。运行 **todo.sh archive** 会将这些项目移动到 done.txt，你可以在该文本文件编辑，并在有时间时将已完成的项目归档。
|
||||
|
||||
#### 设置重复任务
|
||||
|
||||
我有很多重复任务，我需要以每天/周/月来计划。
|
||||
|
||||
![Recurring tasks with the ice_recur add-on][9]
|
||||
|
||||
这就是 todo.txt 的灵活性所在。通过在 **~/.todo.actions.d/** 中使用[附加组件][10]，你可以添加命令并扩展基本 todo.sh 的功能。附加组件基本上是实现特定命令的脚本。对于重复执行的任务，插件 [ice_recur][11] 可以满足。按照页面上的说明操作，你可以以非常灵活的方式设置要重复处理的任务。
|
||||
|
||||
![Todour on MacOS][12]
|
||||
|
||||
目录中有很多附加组件，包括同步到某些云服务。也有链接到桌面或移动端应用的组件，这样你可以随时看到待办列表。
|
||||
|
||||
我只介绍了这个 todo 功能的表面，所以请花点时间深入了解这个工具的强大！它真的帮助我跟上每天的任务。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/1/open-source-to-do-list
|
||||
|
||||
作者：[Kevin Sonney][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/ksonney
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/checklist_todo_clock_time_team.png?itok=1z528Q0y (Team checklist)
|
||||
[2]: https://productivityalchemy.com/
|
||||
[3]: https://www.slideshare.net/AllThingsOpen/getting-to-done-on-the-command-line
|
||||
[4]: https://opensource.com/article/18/2/getting-to-done-agile-linux-command-line
|
||||
[5]: https://opensource.com/sites/default/files/uploads/productivity_7-1.png
|
||||
[6]: http://todotxt.org/
|
||||
[7]: https://orgmode.org/
|
||||
[8]: https://opensource.com/sites/default/files/uploads/productivity_7-2.png (Basic todo.txt list)
|
||||
[9]: https://opensource.com/sites/default/files/uploads/productivity_7-3.png (Recurring tasks with the ice_recur add-on)
|
||||
[10]: https://github.com/todotxt/todo.txt-cli/wiki/Todo.sh-Add-on-Directory
|
||||
[11]: https://github.com/rlpowell/todo-text-stuff
|
||||
[12]: https://opensource.com/sites/default/files/uploads/productivity_7-4.png (Todour on MacOS)
|
||||
Loading…
Reference in New Issue
Block a user