2017年12月

 title=

Phonton OS 专注于容器,是一个非常出色的平台。 —— Jack Wallen

容器在当下的火热,并不是没有原因的。正如之前讨论的,容器可以使您轻松快捷地将新的服务与应用部署到您的网络上,而且并不耗费太多的系统资源。比起专用硬件和虚拟机,容器都是更加划算的,除此之外,他们更容易更新与重用。

更重要的是,容器喜欢 Linux(反之亦然)。不需要太多时间和麻烦,你就可以启动一台 Linux 服务器,运行Docker,然后部署容器。但是,哪种 Linux 发行版最适合部署容器呢?我们的选择很多。你可以使用标准的 Ubuntu 服务器平台(更容易安装 Docker 并部署容器)或者是更轻量级的发行版 —— 专门用于部署容器。

Photon 就是这样的一个发行版。这个特殊的版本是由 VMware 于 2005 年创建的,它包含了 Docker 的守护进程,并可与容器框架(如 Mesos 和 Kubernetes )一起使用。Photon 经过优化可与 VMware vSphere 协同工作,而且可用于裸机、Microsoft AzureGoogle Compute EngineAmazon Elastic Compute Cloud 或者 VirtualBox 等。

Photon 通过只安装 Docker 守护进程所必需的东西来保持它的轻量。而这样做的结果是,这个发行版的大小大约只有 300MB。但这足以让 Linux 的运行一切正常。除此之外,Photon 的主要特点还有:

  • 内核为性能而调整。
  • 内核根据内核自防护项目(KSPP)进行了加固。
  • 所有安装的软件包都根据加固的安全标识来构建。
  • 操作系统在信任验证后启动。
  • Photon 的管理进程可以管理防火墙、网络、软件包,和远程登录在 Photon 机器上的用户。
  • 支持持久卷。
  • Project Lightwave 整合。
  • 及时的安全补丁与更新。

Photon 可以通过 ISO 镜像OVAAmazon Machine ImageGoogle Compute Engine 镜像Azure VHD 安装使用。现在我将向您展示如何使用 ISO 镜像在 VirtualBox 上安装 Photon。整个安装过程大概需要五分钟,在最后您将有一台随时可以部署容器的虚拟机。

创建虚拟机

在部署第一台容器之前,您必须先创建一台虚拟机并安装 Photon。为此,打开 VirtualBox 并点击“新建”按钮。跟着创建虚拟机向导进行配置(根据您的容器将需要的用途,为 Photon 提供必要的资源)。在创建好虚拟机后,您所需要做的第一件事就是更改配置。选择新建的虚拟机(在 VirtualBox 主窗口的左侧面板中),然后单击“设置”。在弹出的窗口中,点击“网络”(在左侧的导航中)。

在“网络”窗口(图1)中,你需要在“连接”的下拉窗口中选择桥接。这可以确保您的 Photon 服务与您的网络相连。完成更改后,单击确定。

 title=

图 1: 更改 Photon 在 VirtualBox 中的网络设置。经许可使用

从左侧的导航选择您的 Photon 虚拟机,点击启动。系统会提示您去加载 ISO 镜像。当您完成之后,Photon 安装程序将会启动并提示您按回车后开始安装。安装过程基于 ncurses(没有 GUI),但它非常简单。

接下来(图2),系统会询问您是要最小化安装,完整安装还是安装 OSTree 服务器。我选择了完整安装。选择您所需要的任意选项,然后按回车继续。

 title=

图 2: 选择您的安装类型。经许可使用

在下一个窗口,选择您要安装 Photon 的磁盘。由于我们将其安装在虚拟机,因此只有一块磁盘会被列出(图3)。选择“自动”按下回车。然后安装程序会让您输入(并验证)管理员密码。在这之后镜像开始安装在您的磁盘上并在不到 5 分钟的时间内结束。

 title=

图 3: 选择安装 Photon 的硬盘。经许可使用

安装完成后,重启虚拟机并使用安装时创建的用户 root 和它的密码登录。一切就绪,你准备好开始工作了。

在开始使用 Docker 之前,您需要更新一下 Photon。Photon 使用 yum 软件包管理器,因此在以 root 用户登录后输入命令 yum update。如果有任何可用更新,则会询问您是否确认(图4)。

 title=

图 4: 更新 Photon。经许可使用

用法

正如我所说的,Photon 提供了部署容器甚至创建 Kubernetes 集群所需要的所有包。但是,在使用之前还要做一些事情。首先要启动 Docker 守护进程。为此,执行以下命令:

systemctl start docker
systemctl enable docker

现在我们需要创建一个标准用户,以便我们可以不用 root 去运行 docker 命令。为此,执行以下命令:

useradd -m USERNAME
passwd USERNAME

其中 “USERNAME” 是我们新增的用户的名称。

接下来,我们需要将这个新用户添加到 “docker” 组,执行命令:

usermod -a -G docker USERNAME

其中 “USERNAME” 是刚刚创建的用户的名称。

注销 root 用户并切换为新增的用户。现在,您已经可以不必使用 sudo 命令或者切换到 root 用户来使用 docker 命令了。从 Docker Hub 中取出一个镜像开始部署容器吧。

一个优秀的容器平台

在专注于容器方面,Photon 毫无疑问是一个出色的平台。请注意,Photon 是一个开源项目,因此没有任何付费支持。如果您对 Photon 有任何的问题,请移步 Photon 项目的 GitHub 下的 Issues,那里可以供您阅读相关问题,或者提交您的问题。如果您对 Photon 感兴趣,您也可以在该项目的官方 GitHub中找到源码。

尝试一下 Photon 吧,看看它是否能够使得 Docker 容器和 Kubernetes 集群的部署更加容易。

欲了解 Linux 的更多信息,可以通过学习 Linux 基金会和 edX 的免费课程,“Linux 入门”


via: https://www.linux.com/learn/intro-to-linux/2017/11/photon-could-be-your-new-favorite-container-os

作者:JACK WALLEN 译者:KeyLD 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

我对 CLI 应用非常感兴趣,因此热衷于使用并分享 CLI 应用。 我之所以更喜欢 CLI 很大原因是因为我在大多数的时候都使用的是字符界面(black screen),已经习惯了使用 CLI 应用而不是 GUI 应用。

我写过很多关于 CLI 应用的文章。 最近我发现了一些谷歌的 CLI 工具,像 “Google Translator”、“Google Calendar” 和 “Google Contacts”。 这里,我想在给大家分享一下。

今天我们要介绍的是 “Google Translator” 工具。 由于我的母语是泰米尔语,我在一天内用了很多次才理解了它的意义。

谷歌翻译为其它语系的人们所广泛使用。

什么是 Translate Shell

Translate Shell (之前叫做 Google Translate CLI) 是一款借助谷歌翻译(默认)、必应翻译、Yandex.Translate 以及 Apertium 来翻译的命令行翻译器。它让你可以在终端访问这些翻译引擎。 Translate Shell 在大多数 Linux 发行版中都能使用。

如何安装 Translate Shell

有三种方法安装 Translate Shell。

  • 下载自包含的可执行文件
  • 手工安装
  • 通过包管理器安装

方法 1 : 下载自包含的可执行文件

下载自包含的可执行文件放到 /usr/bin 目录中。

$ wget git.io/trans
$ chmod +x ./trans
$ sudo mv trans /usr/bin/

方法 2 : 手工安装

克隆 Translate Shell 的 GitHub 仓库然后手工编译。

$ git clone https://github.com/soimort/translate-shell && cd translate-shell
$ make
$ sudo make install

方法 3 : 通过包管理器

有些发行版的官方仓库中包含了 Translate Shell,可以通过包管理器来安装。

对于 Debian/Ubuntu, 使用 APT-GET 命令 或者 APT 命令来安装。

$ sudo apt-get install translate-shell

对于 Fedora, 使用 DNF 命令 来安装。

$ sudo dnf install translate-shell

对于基于 Arch Linux 的系统, 使用 Yaourt 命令Packer 明快 来从 AUR 仓库中安装。

$ yaourt -S translate-shell
or
$ packer -S translate-shell

如何使用 Translate Shell

安装好后,打开终端闭关输入下面命令。 谷歌翻译会自动探测源文本是哪种语言,并且在默认情况下将之翻译成你的 locale 所对应的语言。

$ trans [Words]

下面我将泰米尔语中的单词 “நன்றி” (Nanri) 翻译成英语。 这个单词的意思是感谢别人。

$ trans நன்றி
நன்றி
(Naṉṟi)

Thanks

Definitions of நன்றி
[ தமிழ் -> English ]

noun
    gratitude
        நன்றி
    thanks
        நன்றி

நன்றி
    Thanks

使用下面命令也能将英语翻译成泰米尔语。

$ trans :ta thanks
thanks
/THaNGks/

நன்றி
(Naṉṟi)

Definitions of thanks
[ English -> தமிழ் ]

noun
    நன்றி
        gratitude, thanks

thanks
    நன்றி

要将一个单词翻译到多个语种可以使用下面命令(本例中,我将单词翻译成泰米尔语以及印地语)。

$ trans :ta+hi thanks
thanks
/THaNGks/

நன்றி
(Naṉṟi)

Definitions of thanks
[ English -> தமிழ் ]

noun
    நன்றி
        gratitude, thanks

thanks
    நன்றி

thanks
/THaNGks/

धन्यवाद
(dhanyavaad)

Definitions of thanks
[ English -> हिन्दी ]

noun
    धन्यवाद
        thanks, thank, gratitude, thankfulness, felicitation

thanks
    धन्यवाद, शुक्रिया

使用下面命令可以将多个单词当成一个参数(句子)来进行翻译。(只需要把句子应用起来作为一个参数就行了)。

$ trans :ta "what is going on your life?"
what is going on your life?

உங்கள் வாழ்க்கையில் என்ன நடக்கிறது?
(Uṅkaḷ vāḻkkaiyil eṉṉa naṭakkiṟatu?)

Translations of what is going on your life?
[ English -> தமிழ் ]

what is going on your life?
    உங்கள் வாழ்க்கையில் என்ன நடக்கிறது?

下面命令单独地翻译各个单词。

$ trans :ta curios happy
curios

ஆர்வம்
(Ārvam)

Translations of curios
[ Română -> தமிழ் ]

curios
    ஆர்வம், அறிவாளிகள், ஆர்வமுள்ள, அறிய, ஆர்வமாக
happy
/ˈhapē/

சந்தோஷமாக
(Cantōṣamāka)

Definitions of happy
[ English -> தமிழ் ]

    மகிழ்ச்சியான
        happy, convivial, debonair, gay
    திருப்தி உடைய
        happy

adjective
    இன்பமான
        happy

happy
    சந்தோஷமாக, மகிழ்ச்சி, இனிய, சந்தோஷமா

简洁模式:默认情况下,Translate Shell 尽可能多的显示翻译信息。如果你希望只显示简要信息,只需要加上 -b选项。

$ trans -b :ta thanks
நன்றி

字典模式:加上 -d 可以把 Translate Shell 当成字典来用。

$ trans -d :en thanks
thanks
/THaNGks/

Synonyms
    noun
        - gratitude, appreciation, acknowledgment, recognition, credit

    exclamation
        - thank you, many thanks, thanks very much, thanks a lot, thank you kindly, much obliged, much appreciated, bless you, thanks a million

Examples
    - In short, thanks for everything that makes this city great this Thanksgiving.

    - many thanks

    - There were no thanks in the letter from him, just complaints and accusations.

    - It is a joyful celebration in which Bolivians give thanks for their freedom as a nation.

    - festivals were held to give thanks for the harvest

    - The collection, as usual, received a great response and thanks is extended to all who subscribed.

    - It would be easy to dwell on the animals that Tasmania has lost, but I prefer to give thanks for what remains.

    - thanks for being so helpful

    - It came back on about half an hour earlier than predicted, so I suppose I can give thanks for that.

    - Many thanks for the reply but as much as I tried to follow your advice, it's been a bad week.

    - To them and to those who have supported the office I extend my grateful thanks .

    - We can give thanks and words of appreciation to others for their kind deeds done to us.

    - Adam, thanks for taking time out of your very busy schedule to be with us tonight.

    - a letter of thanks

    - Thank you very much for wanting to go on reading, and thanks for your understanding.

    - Gerry has received a letter of thanks from the charity for his part in helping to raise this much needed cash.

    - So thanks for your reply to that guy who seemed to have a chip on his shoulder about it.

    - Suzanne, thanks for being so supportive with your comments on my blog.

    - She has never once acknowledged my thanks , or existence for that matter.

    - My grateful thanks go to the funders who made it possible for me to travel.

    - festivals were held to give thanks for the harvest

    - All you secretaries who made it this far into the article… thanks for your patience.

    - So, even though I don't think the photos are that good, thanks for the compliments!

    - And thanks for warning us that your secret service requires a motorcade of more than 35 cars.

    - Many thanks for your advice, which as you can see, I have passed on to our readers.

    - Tom Ryan was given a bottle of wine as a thanks for his active involvement in the twinning project.

    - Mr Hill insists he has received no recent complaints and has even been sent a letter of thanks from the forum.

    - Hundreds turned out to pay tribute to a beloved former headteacher at a memorial service to give thanks for her life.

    - Again, thanks for a well written and much deserved tribute to our good friend George.

    - I appreciate your doing so, and thanks also for the compliments about the photos!

See also
    Thanks!, thank, many thanks, thanks to, thanks to you, special thanks, give thanks, thousand thanks, Many thanks!, render thanks, heartfelt thanks, thanks to this

使用下面格式可以使用 Translate Shell 来翻译文件。

$ trans :ta file:///home/magi/gtrans.txt
உங்கள் வாழ்க்கையில் என்ன நடக்கிறது?

下面命令可以让 Translate Shell 进入交互模式。 在进入交互模式之前你需要明确指定源语言和目标语言。本例中,我将英文单词翻译成泰米尔语。

$ trans -shell en:ta thanks
Translate Shell
(:q to quit)
thanks
/THaNGks/

நன்றி
(Naṉṟi)

Definitions of thanks
[ English -> தமிழ் ]

noun
    நன்றி
        gratitude, thanks

thanks
    நன்றி

想知道语言代码,可以执行下面命令。

$ trans -R

或者

$ trans -T
┌───────────────────┬────────────────────┬────────────────────┐
│ Afrikaans      -   af │ Hindi          -   hi │ Punjabi        -   pa │
│ Albanian       -   sq │ Hmong          -  hmn │ Querétaro Otomi-  otq │
│ Amharic        -   am │ Hmong Daw      -  mww │ Romanian       -   ro │
│ Arabic         -   ar │ Hungarian      -   hu │ Russian        -   ru │
│ Armenian       -   hy │ Icelandic      -   is │ Samoan         -   sm │
│ Azerbaijani    -   az │ Igbo           -   ig │ Scots Gaelic   -   gd │
│ Basque         -   eu │ Indonesian     -   id │ Serbian (Cyr...-sr-Cyrl
│ Belarusian     -   be │ Irish          -   ga │ Serbian (Latin)-sr-Latn
│ Bengali        -   bn │ Italian        -   it │ Sesotho        -   st │
│ Bosnian        -   bs │ Japanese       -   ja │ Shona          -   sn │
│ Bulgarian      -   bg │ Javanese       -   jv │ Sindhi         -   sd │
│ Cantonese      -  yue │ Kannada        -   kn │ Sinhala        -   si │
│ Catalan        -   ca │ Kazakh         -   kk │ Slovak         -   sk │
│ Cebuano        -  ceb │ Khmer          -   km │ Slovenian      -   sl │
│ Chichewa       -   ny │ Klingon        -  tlh │ Somali         -   so │
│ Chinese Simp...- zh-CN│ Klingon (pIqaD)tlh-Qaak Spanish        -   es │
│ Chinese Trad...- zh-TW│ Korean         -   ko │ Sundanese      -   su │
│ Corsican       -   co │ Kurdish        -   ku │ Swahili        -   sw │
│ Croatian       -   hr │ Kyrgyz         -   ky │ Swedish        -   sv │
│ Czech          -   cs │ Lao            -   lo │ Tahitian       -   ty │
│ Danish         -   da │ Latin          -   la │ Tajik          -   tg │
│ Dutch          -   nl │ Latvian        -   lv │ Tamil          -   ta │
│ English        -   en │ Lithuanian     -   lt │ Tatar          -   tt │
│ Esperanto      -   eo │ Luxembourgish  -   lb │ Telugu         -   te │
│ Estonian       -   et │ Macedonian     -   mk │ Thai           -   th │
│ Fijian         -   fj │ Malagasy       -   mg │ Tongan         -   to │
│ Filipino       -   tl │ Malay          -   ms │ Turkish        -   tr │
│ Finnish        -   fi │ Malayalam      -   ml │ Udmurt         -  udm │
│ French         -   fr │ Maltese        -   mt │ Ukrainian      -   uk │
│ Frisian        -   fy │ Maori          -   mi │ Urdu           -   ur │
│ Galician       -   gl │ Marathi        -   mr │ Uzbek          -   uz │
│ Georgian       -   ka │ Mongolian      -   mn │ Vietnamese     -   vi │
│ German         -   de │ Myanmar        -   my │ Welsh          -   cy │
│ Greek          -   el │ Nepali         -   ne │ Xhosa          -   xh │
│ Gujarati       -   gu │ Norwegian      -   no │ Yiddish        -   yi │
│ Haitian Creole -   ht │ Pashto         -   ps │ Yoruba         -   yo │
│ Hausa          -   ha │ Persian        -   fa │ Yucatec Maya   -  yua │
│ Hawaiian       -  haw │ Polish         -   pl │ Zulu           -   zu │
│ Hebrew         -   he │ Portuguese     -   pt │                       │
└───────────────────┴────────────────────┴────────────────────┘

想了解更多选项的内容,可以查看其 man 手册。

$ man trans

via: https://www.2daygeek.com/translate-shell-a-tool-to-use-google-translate-from-command-line-in-linux/

作者:Magesh Maruthamuthu 译者:lujun9972 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

有着 23 年历史的著名 Linux 和开源期刊《Linux Journal》结束了,其发行人 Carlie Fairchild 在 12 月 1 日撰文称,《Linux Journal宣布停刊——如果没有奇迹出现的话。

看的出来,Fairchild 的告别信充满了悲伤、释然和获得帮助的一线期望。《Linux Journal》创刊于 1994 年,仅比 Linux 内核发布 0.01 版本的 1991 年晚 3 年,而 1994 年 Linux 内核才刚刚发布了 1.0。其后,2011 年的时候,该杂志停止了纸质杂志的出版,仅发行电子版;而如今,经过 6 年之后,连电子版的发行也难以维系,只能无奈的宣布停刊了。

虽然社区也在讨论是不是可以发起募捐或众筹来帮助它度过难关,但是,问题是我们能帮助它多久?

而另外一方面,《Linux Journal》的停刊,仅仅是时代变迁带来的变化么?这件事会给我们带来什么思考?

以下是 Fairchild 发布的告别信译文:


结束了。

看起来我们走到了尽头。根据计划,虽然我们并不想这样做,11 月这一期的《Linux Journal》是我们最后的一期了。

简单的来说,就是我们没钱了,连同期权也用光了。我们没有一个富有的母公司,也没有一个聚宝盆,从头至尾,我们就不算是一个正常的出版商。很长时间以来,我们一直在勉力挣扎于盈亏线之上,当这个平衡终于翻转时,我们最终坠毁在这个 11 月。

我们所能看到的未来和出版业的过去一样——广告商赞助一个出版物是因为它的品牌和读者——而如今的广告世界更喜欢追逐眼球,喜欢在读者的浏览器中植入信标,在读者看到的每个角度用广告去轰炸他们。但是未来不再,过去已逝。

或许还有一点希望,我们觉得,救世主也许会来;但是那需要接过我们的债务、我们的品牌、归档、域名和订阅者及读者。如果你知道任何人真心愿意接手,一定要让我们知道。否则,来看看 LinuxJournal.com 吧,希望,至少我们的旧归档(可以追溯到 1994 年 4 月创刊,其时 Linux 刚刚发布 1.0)不会消失,这里有许多极棒的内容,以及许多我们怀念的历史。

我们最大的遗憾是,我们没有足够的钱来返还给那些对我们最有价值的人们:我们的订阅者。对此我们表示深切的、真诚的道歉。我们可以为订阅者做的事情有:

《Linux Pro 杂志》为我们的订阅者提供了六期免费杂志,这是一份我们 《Linux Journal》 一直推崇的出版物。在我们需要的时候,他们是第一个出现的人,我们也非常感谢他们的盛情邀请。我们今天刚刚完成了我们的 2017 归档,包括了我们曾经出版过的从开始到最后的每一期。一般我们按 $25 的价格销售它,但是订阅者们这次会免费得到它。请订阅者注意接收邮件了解详情。

我们也希望能得到一些安慰,要知道我们非常、非常地努力才使《Linux Journal》维持下来,我们已经做了太久了,并且以我们所能做到的,以尽可能低、尽可能少的成本来运营。我们基本上是志愿者群体,我们的一些员工已经几个月没有得到报酬了。并且,我们还欠一些自由职业者的钱。出版商对这些情况能承受多少时间是有限度的,而现在已经到了极限了。

这是一件伟大的事情,兄弟们!向那些为我们的诞生、成功和执着而奉献的人们致敬!我们希望列出他们的名字,但是这个名单太长了,以至于我们无法一一列出。但是我们记得你。再次感谢!

本文作者是:《Linux Journal》发行人 Carlie Fairchild

学习如何使用链接,通过从 Linux 文件系统多个位置来访问文件,可以让日常工作变得轻松。

 title=

在我为 opensource.com 写过的关于 Linux 文件系统方方面面的文章中,包括 Linux 的 EXT4 文件系统的历史、特性以及最佳实践在 Linux 中管理设备Linux 文件系统概览用户指南:逻辑卷管理,我曾简要的提到过 Linux 文件系统一个有趣的特性,它允许用户从多个位置来访问 Linux 文件目录树中的文件来简化一些任务。

Linux 文件系统中有两种 链接 link 硬链接 hard link 软链接 soft link 。虽然二者差别显著,但都用来解决相似的问题。它们都提供了对单个文件的多个目录项(引用)的访问,但实现却大为不同。链接的强大功能赋予了 Linux 文件系统灵活性,因为一切皆是文件

举个例子,我曾发现一些程序要求特定的版本库方可运行。 当用升级后的库替代旧库后,程序会崩溃,提示旧版本库缺失。通常,库名的唯一变化就是版本号。出于直觉,我仅仅给程序添加了一个新的库链接,并以旧库名称命名。我试着再次启动程序,运行良好。程序就是一个游戏,人人都明白,每个玩家都会尽力使游戏进行下去。

事实上,几乎所有的应用程序链接库都使用通用的命名规则,链接名称中包含了主版本号,链接所指向的文件的文件名中同样包含了小版本号。再比如,程序的一些必需文件为了迎合 Linux 文件系统规范,从一个目录移动到另一个目录中,系统为了向后兼容那些不能获取这些文件新位置的程序在旧的目录中存放了这些文件的链接。如果你对 /lib64 目录做一个长清单列表,你会发现很多这样的例子。

lrwxrwxrwx.  1 root root       36 Dec  8  2016 cracklib_dict.hwm -> ../../usr/share/cracklib/pw_dict.hwm 
lrwxrwxrwx.  1 root root       36 Dec  8  2016 cracklib_dict.pwd -> ../../usr/share/cracklib/pw_dict.pwd 
lrwxrwxrwx.  1 root root       36 Dec  8  2016 cracklib_dict.pwi -> ../../usr/share/cracklib/pw_dict.pwi
lrwxrwxrwx.  1 root root       27 Jun  9  2016 libaccountsservice.so.0 -> libaccountsservice.so.0.0.0 
-rwxr-xr-x.  1 root root   288456 Jun  9  2016 libaccountsservice.so.0.0.0 
lrwxrwxrwx   1 root root       15 May 17 11:47 libacl.so.1 -> libacl.so.1.1.0 
-rwxr-xr-x   1 root root    36472 May 17 11:47 libacl.so.1.1.0 
lrwxrwxrwx.  1 root root       15 Feb  4  2016 libaio.so.1 -> libaio.so.1.0.1 
-rwxr-xr-x.  1 root root     6224 Feb  4  2016 libaio.so.1.0.0 
-rwxr-xr-x.  1 root root     6224 Feb  4  2016 libaio.so.1.0.1 
lrwxrwxrwx.  1 root root       30 Jan 16 16:39 libakonadi-calendar.so.4 -> libakonadi-calendar.so.4.14.26 
-rwxr-xr-x.  1 root root   816160 Jan 16 16:39 libakonadi-calendar.so.4.14.26 
lrwxrwxrwx.  1 root root       29 Jan 16 16:39 libakonadi-contact.so.4 -> libakonadi-contact.so.4.14.26 

/lib64 目录下的一些链接

在上面展示的 /lib64 目录清单列表中,文件模式第一个字母 l (小写字母 l)表示这是一个软链接(又称符号链接)。

硬链接

Linux 的 EXT4 文件系统的历史、特性以及最佳实践一文中,我曾探讨过这样一个事实,每个文件都有一个包含该文件信息的 inode,包含了该文件的位置信息。上述文章中的图2展示了一个指向 inode 的单一目录项。每个文件都至少有一个目录项指向描述该文件信息的 inode ,目录项是一个硬链接,因此每个文件至少都有一个硬链接。

如下图 1 所示,多个目录项指向了同一 inode 。这些目录项都是硬链接。我曾在三个目录项中使用波浪线 (~) 的缩写,这是用户目录的惯例表示,因此在该例中波浪线等同于 /home/user 。值得注意的是,第四个目录项是一个完全不同的目录,/home/shared,可能是该计算机上用户的共享文件目录。

fig1directory_entries.png

图 1

硬链接被限制在一个单一的文件系统中。此处的“文件系统” 是指挂载在特定挂载点上的分区或逻辑卷,此例中是 /home。这是因为在每个文件系统中的 inode 号都是唯一的。而在不同的文件系统中,如 /var/opt,会有和 /home 中相同的 inode 号。

因为所有的硬链接都指向了包含文件元信息的单一 inode ,这些属性都是文件的一部分,像所属关系、权限、到该 inode 的硬链接数目,对每个硬链接来说这些特性没有什么不同的。这是一个文件所具有的一组属性。唯一能区分这些文件的是包含在 inode 信息中的文件名。链接到同一目录中的单一文件/ inode 的硬链接必须拥有不同的文件名,这是基于同一目录下不能存在重复的文件名的事实的。

文件的硬链接数目可通过 ls -l 来查看,如果你想查看实际节点号,可使用 ls -li 命令。

符号(软)链接

硬链接和软链接(也称为 符号链接 symlink )的区别在于,硬链接直接指向属于该文件的 inode ,而软链接直接指向一个目录项,即指向一个硬链接。因为软链接指向的是一个文件的硬链接而非该文件的 inode ,所以它们并不依赖于 inode 号,这使得它们能跨越不同的文件系统、分区和逻辑卷起作用。

软链接的缺点是,一旦它所指向的硬链接被删除或重命名后,该软链接就失效了。软链接虽然还在,但所指向的硬链接已不存在。所幸的是,ls 命令能以红底白字的方式在其列表中高亮显示失效的软链接。

实验项目: 链接实验

我认为最容易理解链接用法及其差异的方法是动手搭建一个项目。这个项目应以非超级用户的身份在一个空目录下进行。我创建了 ~/temp 目录做这个实验,你也可以这么做。这么做可为项目创建一个安全的环境且提供一个新的空目录让程序运作,如此以来这儿仅存放和程序有关的文件。

初始工作

首先,在你要进行实验的目录下为该项目中的任务创建一个临时目录,确保当前工作目录(PWD)是你的主目录,然后键入下列命令。

mkdir temp

使用这个命令将当前工作目录切换到 ~/temp

cd temp

实验开始,我们需要创建一个能够链接到的文件,下列命令可完成该工作并向其填充内容。

du -h > main.file.txt

使用 ls -l 长列表命名确认文件正确地创建了。运行结果应类似于我的。注意文件大小只有 7 字节,但你的可能会有 1~2 字节的变动。

[dboth@david temp]$ ls -l 
total 4 
-rw-rw-r-- 1 dboth dboth 7 Jun 13 07:34 main.file.txt

在列表中,文件模式串后的数字 1 代表存在于该文件上的硬链接数。现在应该是 1 ,因为我们还没有为这个测试文件建立任何硬链接。

对硬链接进行实验

硬链接创建一个指向同一 inode 的新目录项,当为文件添加一个硬链接时,你会看到链接数目的增加。确保当前工作目录仍为 ~/temp。创建一个指向 main.file.txt 的硬链接,然后查看该目录下文件列表。

[dboth@david temp]$ ln main.file.txt link1.file.txt 
[dboth@david temp]$ ls -l 
total 8 
-rw-rw-r-- 2 dboth dboth 7 Jun 13 07:34 link1.file.txt 
-rw-rw-r-- 2 dboth dboth 7 Jun 13 07:34 main.file.txt

目录中两个文件都有两个链接且大小相同,时间戳也一样。这就是有一个 inode 和两个硬链接(即该文件的目录项)的一个文件。再建立一个该文件的硬链接,并列出目录清单内容。你可以建立硬链接: link1.file.txtmain.file.txt

[dboth@david temp]$ ln link1.file.txt link2.file.txt ; ls -l
total 16 
-rw-rw-r-- 3 dboth dboth 7 Jun 13 07:34 link1.file.txt 
-rw-rw-r-- 3 dboth dboth 7 Jun 13 07:34 link2.file.txt 
-rw-rw-r-- 3 dboth dboth 7 Jun 13 07:34 main.file.txt

注意,该目录下的每个硬链接必须使用不同的名称,因为同一目录下的两个文件不能拥有相同的文件名。试着创建一个和现存链接名称相同的硬链接。

[dboth@david temp]$ ln main.file.txt link2.file.txt 
ln: failed to create hard link 'link2.file.txt': File exists

显然不行,因为 link2.file.txt 已经存在。目前为止我们只在同一目录下创建硬链接,接着在临时目录的父目录(你的主目录)中创建一个链接。

[dboth@david temp]$ ln main.file.txt ../main.file.txt ; ls -l ../main*
-rw-rw-r--    4 dboth dboth     7 Jun 13 07:34 main.file.txt

上面的 ls 命令显示 main.file.txt 文件确实存在于主目录中,且与该文件在 temp 目录中的名称一致。当然它们不是不同的文件,它们是同一文件的两个链接,指向了同一文件的目录项。为了帮助说明下一点,在 temp 目录中添加一个非链接文件。

[dboth@david temp]$ touch unlinked.file ; ls -l
total 12
-rw-rw-r-- 4 dboth dboth 7 Jun 13 07:34 link1.file.txt
-rw-rw-r-- 4 dboth dboth 7 Jun 13 07:34 link2.file.txt
-rw-rw-r-- 4 dboth dboth 7 Jun 13 07:34 main.file.txt
-rw-rw-r-- 1 dboth dboth 0 Jun 14 08:18 unlinked.file

使用 ls 命令的 i 选项查看 inode 的硬链接号和新创建文件的硬链接号。

[dboth@david temp]$ ls -li
total 12
657024 -rw-rw-r-- 4 dboth dboth 7 Jun 13 07:34 link1.file.txt
657024 -rw-rw-r-- 4 dboth dboth 7 Jun 13 07:34 link2.file.txt
657024 -rw-rw-r-- 4 dboth dboth 7 Jun 13 07:34 main.file.txt
657863 -rw-rw-r-- 1 dboth dboth 0 Jun 14 08:18 unlinked.file

注意上面文件模式左边的数字 657024 ,这是三个硬链接文件所指的同一文件的 inode 号,你也可以使用 i 选项查看主目录中所创建的链接的节点号,和该值相同。而那个只有一个链接的 inode 号和其他的不同,在你的系统上看到的 inode 号或许不同于本文中的。

接着改变其中一个硬链接文件的大小。

[dboth@david temp]$ df -h > link2.file.txt ; ls -li
total 12
657024 -rw-rw-r-- 4 dboth dboth 1157 Jun 14 14:14 link1.file.txt
657024 -rw-rw-r-- 4 dboth dboth 1157 Jun 14 14:14 link2.file.txt
657024 -rw-rw-r-- 4 dboth dboth 1157 Jun 14 14:14 main.file.txt
657863 -rw-rw-r-- 1 dboth dboth    0 Jun 14 08:18 unlinked.file

现在所有的硬链接文件大小都比原来大了,因为多个目录项都链接着同一文件。

下个实验在我的电脑上会出现这样的结果,是因为我的 /tmp 目录在一个独立的逻辑卷上。如果你有单独的逻辑卷或文件系统在不同的分区上(如果未使用逻辑卷),确定你是否能访问那个分区或逻辑卷,如果不能,你可以在电脑上挂载一个 U 盘,如果上述方式适合你,你可以进行这个实验。

试着在 /tmp 目录中建立一个 ~/temp 目录下文件的链接(或你的文件系统所在的位置)。

[dboth@david temp]$ ln link2.file.txt /tmp/link3.file.txt
ln: failed to create hard link '/tmp/link3.file.txt' => 'link2.file.txt': 
Invalid cross-device link

为什么会出现这个错误呢? 原因是每一个单独的可挂载文件系统都有一套自己的 inode 号。简单的通过 inode 号来跨越整个 Linux 文件系统结构引用一个文件会使系统困惑,因为相同的节点号会存在于每个已挂载的文件系统中。

有时你可能会想找到一个 inode 的所有硬链接。你可以使用 ls -li 命令。然后使用 find 命令找到所有硬链接的节点号。

[dboth@david temp]$ find . -inum 657024 
./main.file.txt
./link1.file.txt
./link2.file.txt

注意 find 命令不能找到所属该节点的四个硬链接,因为我们在 ~/temp 目录中查找。 find 命令仅在当前工作目录及其子目录中查找文件。要找到所有的硬链接,我们可以使用下列命令,指定你的主目录作为起始查找条件。

[dboth@david temp]$ find ~ -samefile main.file.txt 
/home/dboth/temp/main.file.txt
/home/dboth/temp/link1.file.txt
/home/dboth/temp/link2.file.txt
/home/dboth/main.file.txt

如果你是非超级用户,没有权限,可能会看到错误信息。这个命令也使用了 -samefile 选项而不是指定文件的节点号。这个效果和使用 inode 号一样且更容易,如果你知道其中一个硬链接名称的话。

对软链接进行实验

如你刚才看到的,不能跨越文件系统边界创建硬链接,即在逻辑卷或文件系统中从一个文件系统到另一个文件系统。软链接给出了这个问题的解决方案。虽然它们可以达到相同的目的,但它们是非常不同的,知道这些差异是很重要的。

让我们在 ~/temp 目录中创建一个符号链接来开始我们的探索。

[dboth@david temp]$ ln -s link2.file.txt link3.file.txt ; ls -li
total 12
657024 -rw-rw-r-- 4 dboth dboth 1157 Jun 14 14:14 link1.file.txt
657024 -rw-rw-r-- 4 dboth dboth 1157 Jun 14 14:14 link2.file.txt
658270 lrwxrwxrwx 1 dboth dboth   14 Jun 14 15:21 link3.file.txt -> 
link2.file.txt
657024 -rw-rw-r-- 4 dboth dboth 1157 Jun 14 14:14 main.file.txt
657863 -rw-rw-r-- 1 dboth dboth    0 Jun 14 08:18 unlinked.file

拥有节点号 657024 的那些硬链接没有变化,且硬链接的数目也没有变化。新创建的符号链接有不同的 inode 号 658270。 名为 link3.file.txt 的软链接指向了 link2.file.txt 文件。使用 cat 命令查看 link3.file.txt 文件的内容。符号链接的 inode 信息以字母 l (小写字母 l)开头,意味着这个文件实际是个符号链接。

上例中软链接文件 link3.file.txt 的大小只有 14 字节。这是文本内容 link3.file.txt 的大小,即该目录项的实际内容。目录项 link3.file.txt 并不指向一个 inode ;它指向了另一个目录项,这在跨越文件系统建立链接时很有帮助。现在试着创建一个软链接,之前在 /tmp 目录中尝试过的。

[dboth@david temp]$ ln -s /home/dboth/temp/link2.file.txt 
/tmp/link3.file.txt ; ls -l /tmp/link*
lrwxrwxrwx 1 dboth dboth 31 Jun 14 21:53 /tmp/link3.file.txt -> 
/home/dboth/temp/link2.file.txt

删除链接

当你删除硬链接或硬链接所指的文件时,需要考虑一些问题。

首先,让我们删除硬链接文件 main.file.txt。注意指向 inode 的每个目录项就是一个硬链接。

[dboth@david temp]$ rm main.file.txt ; ls -li
total 8
657024 -rw-rw-r-- 3 dboth dboth 1157 Jun 14 14:14 link1.file.txt
657024 -rw-rw-r-- 3 dboth dboth 1157 Jun 14 14:14 link2.file.txt
658270 lrwxrwxrwx 1 dboth dboth   14 Jun 14 15:21 link3.file.txt -> 
link2.file.txt
657863 -rw-rw-r-- 1 dboth dboth    0 Jun 14 08:18 unlinked.file

main.file.txt 是该文件被创建时所创建的第一个硬链接。现在删除它,仍然保留着原始文件和硬盘上的数据以及所有剩余的硬链接。要删除原始文件,你必须删除它的所有硬链接。

现在删除 link2.file.txt 硬链接文件。

[dboth@david temp]$ rm link2.file.txt ; ls -li 
total 8 
657024 -rw-rw-r-- 3 dboth dboth 1157 Jun 14 14:14 link1.file.txt 
658270 lrwxrwxrwx 1 dboth dboth   14 Jun 14 15:21 link3.file.txt -> 
link2.file.txt 
657024 -rw-rw-r-- 3 dboth dboth 1157 Jun 14 14:14 main.file.txt 
657863 -rw-rw-r-- 1 dboth dboth    0 Jun 14 08:18 unlinked.file

注意软链接的变化。删除软链接所指的硬链接会使该软链接失效。在我的系统中,断开的链接用颜色高亮显示,目标的硬链接会闪烁显示。如果需要修复这个损坏的软链接,你需要在同一目录下建立一个和旧链接相同名字的硬链接,只要不是所有硬链接都已删除就行。您还可以重新创建链接本身,链接保持相同的名称,但指向剩余的硬链接中的一个。当然如果软链接不再需要,可以使用 rm 命令删除它们。

unlink 命令在删除文件和链接时也有用。它非常简单且没有选项,就像 rm 命令一样。然而,它更准确地反映了删除的基本过程,因为它删除了目录项与被删除文件的链接。

写在最后

我用过这两种类型的链接很长一段时间后,我开始了解它们的能力和特质。我为我所教的 Linux 课程编写了一个实验室项目,以充分理解链接是如何工作的,并且我希望增进你的理解。

(题图: Paul Lewin,Opensource.com 修改。 CC BY-SA 2.0


作者简介:

戴维.布斯 - 戴维.布斯是 Linux 和开源倡导者,居住在北卡罗莱纳的罗列 。他在 IT 行业工作了四十年,为 IBM 工作了 20 多年的 OS/2。在 IBM 时,他在 1981 年编写了最初的 IBM PC 的第一个培训课程。他为 RedHat 教授过 RHCE 班,并曾在 MCI Worldcom、思科和北卡罗莱纳州工作。他已经用 Linux 和开源软件工作将近 20 年了。


via: https://opensource.com/article/17/6/linking-linux-filesystem

作者:David Both 译者:yongshouzhang 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

想知道容器编排管理和 K8S 的最新展望么?来看看专家怎么说。

 title=

如果你想对容器在未来的发展方向有一个整体把握,那么你一定要跟着钱走,看看钱都投在了哪里。当然了,有很多很多的钱正在投入容器的进一步发展。相关研究预计 2020 年容器技术的投入将占有 27 亿美元 的市场份额。而在 2016 年,容器相关技术投入的总额为 7.62 亿美元,只有 2020 年投入预计的三分之一。巨额投入的背后是一些显而易见的基本因素,包括容器化的迅速增长以及并行化的大趋势。随着容器被大面积推广和使用,容器编排管理也会被理所当然的推广应用起来。

来自 The new stack 的调研数据表明,容器的推广使用是编排管理被推广的主要的催化剂。根据调研参与者的反馈数据,在已经将容器技术使用到生产环境中的使用者里,有六成使用者正在将 Kubernetes(K8S)编排管理广泛的应用在生产环境中,另外百分之十九的人员则表示他们已经处于部署 K8S 的初级阶段。在容器部署初期的使用者当中,虽然只有百分之五的人员表示已经在使用 K8S ,但是百分之五十八的人员表示他们正在计划和准备使用 K8S。总而言之,容器和 Kubernetes 的关系就好比是鸡和蛋一样,相辅相成紧密关联。众多专家一致认为编排管理工具对容器的长周期管理 以及其在市场中的发展有至关重要的作用。正如 Cockroach 实验室 的 Alex Robinson 所说,容器编排管理被更广泛的拓展和应用是一个总体的大趋势。毫无疑问,这是一个正在快速演变的领域,且未来潜力无穷。鉴于此,我们对 Robinson 和其他的一些容器的实际使用和推介者做了采访,来从他们作为容器技术的践行者的视角上展望一下容器编排以及 K8S 的下一步发展。

容器编排将被主流接受

像任何重要技术的转型一样,我们就像是处在一个高崖之上一般,在经过了初期步履蹒跚的跋涉之后将要来到一望无际的广袤平原。广大的新天地和平实真切的应用需求将会让这种新技术在主流应用中被迅速推广,尤其是在大企业环境中。正如 Alex Robinson 说的那样,容器技术的淘金阶段已经过去,早期的技术革新创新正在减速,随之而来的则是市场对容器技术的稳定性和可用性的强烈需求。这意味着未来我们将不会再见到大量的新的编排管理系统的涌现,而是会看到容器技术方面更多的安全解决方案,更丰富的管理工具,以及基于目前主流容器编排系统的更多的新特性。

更好的易用性

人们将在简化容器的部署方面下大功夫,因为容器部署的初期工作对很多公司和组织来说还是比较复杂的,尤其是容器的长期管理维护更是需要投入大量的精力。正如 Codemill AB 公司的 My Karlsson 所说,容器编排技术还是太复杂了,这导致很多使用者难以娴熟驾驭和充分利用容器编排的功能。很多容器技术的新用户都需要花费很多精力,走很多弯路,才能搭建小规模的或单个的以隔离方式运行的容器系统。这种现象在那些没有针对容器技术设计和优化的应用中更为明显。在简化容器编排管理方面有很多优化可以做,这些优化和改造将会使容器技术更加具有可用性。

在混合云以及多云技术方面会有更多侧重

随着容器和容器编排技术被越来越多的使用,更多的组织机构会选择扩展他们现有的容器技术的部署,从之前的把非重要系统部署在单一环境的使用情景逐渐过渡到更加复杂的使用情景。对很多公司来说,这意味着他们必须开始学会在 混合云多云 的环境下,全局化的去管理那些容器化的应用和微服务。正如红帽 Openshift 部门产品战略总监 Brian Gracely 所说,“容器和 K8S 技术的使用使得我们成功的实现了混合云以及应用的可移植性。结合 Open Service Broker API 的使用,越来越多的结合私有云和公有云资源的新应用将会涌现出来。” 据 CloudBees 公司的高级工程师 Carlos Sanchez 分析,联合服务(Federation)将会得到极大推动,使一些诸如多地区部署和多云部署等的备受期待的新特性成为可能。

想知道 CIO 们对混合云和多云的战略构想么? 请参看我们的这条相关资源, [Hybrid Cloud: The IT leader's guide。 ]

平台和工具的持续整合及加强

对任何一种科技来说,持续的整合和加强从来都是大势所趋;容器编排管理技术在这方面也不例外。来自 Sumo Logic 的首席分析师 Ben Newton 表示,随着容器化渐成主流,软件工程师们正在很少数的一些技术上做持续整合加固的工作,来满足他们的一些微应用的需求。容器和 K8S 将会毫无疑问的成为容器编排管理方面的主流平台,并轻松碾压其它的一些小众平台方案。因为 K8S 提供了一个相当清晰的可以摆脱各种特有云生态的途径,K8S 将被大量公司使用,逐渐形成一个不依赖于某个特定云服务的 “中立云” cloud-neutral

K8S 的下一站

来自 Alcide 的 CTO 和联合创始人 Gadi Naor 表示,K8S 将会是一个有长期和远景发展的技术,虽然我们的社区正在大力推广和发展 K8S,K8S 仍有很长的路要走。

专家们对日益流行的 K8S 平台也作出了以下一些预测:

来自 Alcide 的 Gadi Naor 表示: “运营商会持续演进并趋于成熟,直到在 K8S 上运行的应用可以完全自治。利用 OpenTracing 和诸如 istio 技术的 service mesh 架构,在 K8S 上部署和监控微应用将会带来很多新的可能性。”

来自 Red Hat 的 Brian Gracely 表示: “K8S 所支持的应用的种类越来越多。今后在 K8S 上,你不仅可以运行传统的应用程序,还可以运行原生的云应用、大数据应用以及 HPC 或者基于 GPU 运算的应用程序,这将为灵活的架构设计带来无限可能。”

来自 Sumo Logic 的 Ben Newton 表示: “随着 K8S 成为一个具有统治地位的平台,我预计更多的操作机制将会被统一化,尤其是 K8S 将和第三方管理和监控平台融合起来。”

来自 CloudBees 的 Carlos Sanchez 表示: “在不久的将来我们就能看到不依赖于 Docker 而使用其它运行时环境的系统,这将会有助于消除任何可能的 lock-in 情景“ 编辑提示:[CRI-O 就是一个可以借鉴的例子。]“而且我期待将来会出现更多的针对企业环境的存储服务新特性,包括数据快照以及在线的磁盘容量的扩展。”

来自 Cockroach Labs 的 Alex Robinson 表示: “ K8S 社区正在讨论的一个重大发展议题就是加强对有状态程序的管理。目前在 K8S 平台下,实现状态管理仍然非常困难,除非你所使用的云服务商可以提供远程固定磁盘。现阶段也有很多人在多方面试图改善这个状况,包括在 K8S 平台内部以及在外部服务商一端做出的一些改进。”


via: https://enterprisersproject.com/article/2017/11/containers-and-kubernetes-whats-next

作者:Kevin Casey 译者:yunfengHe 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

回复:amarao 在块层介绍第一部分:块 I/O 层 中提的问题

先前的文章:块层介绍第一部分:块 I/O 层

嗨,

你在这里描述的问题与块层不直接相关。这可能是一个驱动错误、可能是一个 SCSI 层错误,但绝对不是一个块层的问题。

不幸的是,报告针对 Linux 的错误是一件难事。有些开发者拒绝去看 bugzilla,有些开发者喜欢它,有些(像我这样)只能勉强地使用它。

另一种方法是发送电子邮件。为此,你需要选择正确的邮件列表,还有也许是正确的开发人员,当他们心情愉快,或者不是太忙或者不是假期时找到它们。有些人会努力回复所有,有些是完全不可预知的 - 这对我来说通常会发送一个补丁,包含一些错误报告。如果你只是有一个你自己几乎都不了解的 bug,那么你的预期响应率可能会更低。很遗憾,但这是是真的。

许多 bug 都会得到回应和处理,但很多 bug 都没有。

我不认为说没有人关心是公平的,但是没有人认为它如你想的那样重要是有可能的。如果你想要一个解决方案,那么你需要驱动它。一个驱动它的方法是花钱请顾问或者与经销商签订支持合同。我怀疑你的情况没有上面的可能。另一种方法是了解代码如何工作,并自己找到解决方案。很多人都这么做,但是这对你来说可能不是一种选择。另一种方法是在不同的相关论坛上不断提出问题,直到得到回复。坚持可以见效。你需要做好准备去执行任何你所要求的测试,可能包括建立一个新的内核来测试。

如果你能在最近的内核(4.12 或者更新)上复现这个 bug,我建议你邮件报告给 [email protected][email protected] 和我([email protected])(注意你不必订阅这些列表来发送邮件,只需要发送就行)。描述你的硬件以及如何触发问题的。

包含所有进程状态是 “D” 的栈追踪。你可以用 “cat /proc/$PID/stack” 来得到它,这里的 “$PID” 是进程的 pid。

确保避免抱怨或者说这个已经坏了好几年了以及这是多么严重不足。没有人关心这个。我们关心的是 bug 以及如何修复它。因此只要报告相关的事实就行。

尝试在邮件中而不是链接到其他地方的链接中包含所有事实。有时链接是需要的,但是对于你的脚本,它只有 8 行,所以把它包含在邮件中就行(并避免像 “fuckup” 之类的描述。只需称它为 “坏的” broken 或者类似的)。同样确保你的邮件发送的不是 HTML 格式。我们喜欢纯文本。HTML 被所有的 @vger.kernel.org 邮件列表拒绝。你或许需要配置你的邮箱程序不发送 HTML。


via: https://lwn.net/Articles/737655/

作者:neilbrown 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出