标签 redhat 下的文章

转眼都到了2024年了。回看一下2023年,我居然发布了整整16个乱七八糟的内容,我实在太勤奋了。

那么,作为一个以类unix系统教程碎片为主的频道,在新年之际跟你分享一下2023年的一些变化。

更新频率降低的最主要原因就是莫名其妙的没有太闲着,而没有太闲着导致的结果就是很少打开家中常用的电脑,而不用家中电脑就意味着我这一年实际上很少使用Linux或者macOS系统。可以说,我在2020年换掉archlinux时候的预言在2023年得到了完美的体现。属实是:不是不报时辰未到。

但即使使用的频率很低,我还是将ubuntuunity更换到了Debian12。这可能是我这一年中最大的一个更改,这其中的具体原因我也有分享过,可以回看一下。

提到了乌班图,这让我想到了2023年乌班图的一个改变人生轨迹的变化:引入了基于flutter的应用商店。这项调整体现在了前几个月发布的乌班图23.10版本中,用以替代老朋友——乌班图软件中心。相对来说,新版本的商店有着更现代、更流畅、更一致的使用体验,可能也会助力乌班图全局snap化的布局。

可能你觉得使用flutter开发应用商店与全局snap化没啥关联,不过乌班图在2023年2月宣布,官方版本不再支持flatpak格式软件包开箱即用你又如何看待呢?很明显,乌班图为了推广并应用自己发布的snap格式软件包在自己的系统上不遗余力,撤销开箱支持flatpak可以说是最明显的一项措施。不过仅仅是无法开箱即用,你还是可以手动部署相关的程序以恢复flatpak支持。

顺带一提,即将推出的ubuntu24.04为长期支持版本也有一个新的变化,那便是它将可以获得长达12年的更新支持——当然,这需要你注册ubuntu pro。不过这项服务对于个人用户来说是免费的,如果你习惯并长期使用乌班图的话,安装这个版本并加入ubuntu pro也不失为一个好的选择。

你方唱罢我登场,与ubuntu所处的Debian分支相对的,则是RHEL分支中一个改变人生轨迹的变化:RHEL与2023年中旬宣布限制其源码访问。现在看来这个大概是转变CentOS性质的接续步骤:目前的CentOS完全可以说是RHEL的测试版,而曾经的CentOS则可以看作是RHEL的免费版。两者位置的变更似的RHEL可以将全部精力投入到企业客户上,而无需再考虑普通用户。这个消息在刚发布时反响剧烈,不过就目前来看,这更多的改变了RHEL下游发行版的生存轨迹,对于其他分支,甚至RHEL本身的企业用户来说,影响不大——暂时不大。

现在从发行版层面剥离出来,看看内核层面改变人生轨迹的变化:支持周期从六年缩短至两年了——我是说LTS内核。这个变化大概对用户来说影响不大,毕竟现在常见的发行版,要么像SuSE,不更新内核主版本,但自己长期单独维护,以至于跟用新内核没啥区别;要么就像Arch,有新的就直接给更新上来了。但支持周期的缩短对与内核维护人员来说可是重大利好——再也不用管理那么多没啥人用的旧版本内核了。

上面这些2023年Linux世界的变化是好是坏还请各位评判。不过,Linux版Steam使用率超过macOS,从哪种角度来看到可以算是2023年Linux世界一个不错的消息吧——当然了,这俩货加起来都追不上Windows的零头,不过,这至少证明Valve这几年在Linux游戏领域所做的不懈努力不是白费的——要知道,为了能让Linux运行Steam 中大多数的游戏,Valve从大概疫情前便开始基于wine来开发Linux 的游戏兼容层proton,并在这些年中取得了极大的进步。截止目前,Steam上热门游戏通过官方测试可以运行的已经超过了10000款,而根据玩家的测试,这个数量可以上升至大约17000款。我想这对于一名普通玩家来说已经不是一个小数字了。

但诚然,目前这个兼容层还不是十全十美:比如联网游玩的游戏,反作弊插件目前还无法正常运行。但车到山前必有路,由于Valve的proton套件是开源的,因此针对部分特定游戏,有个人开发者定制了proton套件,使得可以通过定制版套件达到正常运行带有反作弊插件游戏的目的。不过这些仍只是个例,Linux联网游戏任重而道远。

以上便是跟各位分享的2023年Linux世界的一些重大的、改变人生轨迹的变化。祝各位能在这曲里拐弯的人生中好好生活。

视频点此

Linux系统会为每一个用户建立一个home目录,其中有几个金刚路径,如桌面、文档、音乐、下载等等。通常来讲,在图形界面下使用这几个文件夹可能不会意识到什么问题,但如果使用终端的话,你也许会发现:在不同的发行版里,这几个金刚文件夹的实际名称可能是中文,可能是英文。也就是说虽然在图形界面下,文件夹名字显示为“桌面”,但实际上需要在终端中输入cd ~/Desktop才能进入桌面文件夹。这个是为什么呢?

这个问题——其实也不是问题。因为只是设置存在一些差异。

一、如果你是图形界面用户

以KDE为例,你可以发现在设置个性化-应用程序-位置项中可以随意定义这几个金刚文件夹的路径。因此如果想把中文路径调整为英文,直接输入即可。确定时按照提示,系统会自动完成文件夹的重命名操作。
另外,由于可以随意自定义,所以理论上如果你有长期挂载一个网盘当作本地扩容的分区,那么你也可以通过这个设置,把这个网盘当作某一个金刚文件夹对应的路径。

二、如果你是终端用户

这个文件夹映射关系保存在~/.config/user-dirs.dirs文件中,因此只需要修改对应的路径即可实现调整。但是需要注意,由于终端无法完成自动重命名,所以如果需要保留文件夹中的数据,需要在修改路径之后手工将原先的文件夹修改成对应的名称才能保证继续映射。

视频点此

如果你需要在Linux中使用Xbox one无线手柄,那么这个软件包或许可以帮助到你。

当然如果你用的是最早的xbox手柄,或者有线连接Xbox one使用的话,那么在Linux下面是可以开箱即用的。唯独对于蓝牙或者接收器方式连接会出现问题。这时我们只需安装一个包:xpadneo。这是针对Linux平台的xboxone开源驱动,我用了很长时间了,通过steam的手柄设置来分配游戏中按键是很完美的,游戏用的延迟也非常低,是一个完全可以使用的开源驱动。

直接去往它的GitHub,就可以看到安装教程。如果你想的话,直接全部下载,然后终端执行./install.sh即可。但如果你跟我一样习惯于通过包管理器统一管理的话,那对于arch用户,直接通过aur即可安装,opensuse用户,通过opi搜索xpadneo,选择不带后缀的选项,再选择home:FrauHolle源即可自动安装。ubuntu好像可以通过apt直接安装。待安装完成,重启,便可以通过蓝牙正常连接xboxone手柄了。

第一期第二期

前两天收到了这么一条私信。

这倒是提醒了我一个很早就想分享的一个小技巧,如何简单的使用不对应自己发行版的安装包程序。但在这之前想先跟各位铺垫一些内容:Linux安装包,或者说,一个二进制程序的安装包实际上在做什么。

macOS软件的安装过程能更好地展现。打开一个下载好的安装包,会看到一个应用程序图标和一个applications文件夹。

安装程序的话,只需将应用图标拖到applications文件夹上面,然后我们就可以在访达的应用程序文件夹下看到这个应用。在macOS中,应用程序文件夹的路径是固定的/Applications, 而安装程序的applications文件夹图标下面有一个快捷方式的小箭头,查看它的属性的话就可以看到,它指向的就是我们电脑中的应用程序文件夹(关注下图原身指向的路径)。

到此就可以看出,macOS应用的安装过程其实就是把应用复制到了应用程序文件夹中。而如果我们右键应用程序—显示包内容,还可以查看这个应用所拥有的各种文件。因此总的来说,macOS应用的安装过程其实就是把这个应用程序的文件夹复制到了一个指定的位置而已。

由此,我们可以类比一下Windows的安装程序。它与macOS的过程其实是一样的,只不过Windows允许用户自己选择应用程序的这一堆文件要复制到哪里,然后自动帮用户进行复制操作(当然,对于Windows,安装程序可能还需要进行注册表编辑的操作)。

那么Linux的安装包呢?

由于Linux更多的是在用包管理器进行操作,所以Linux用户可能很少去关注应用的下载和安装这两个前期过程。这时我就要推荐你去看看我之前的使用obs和aur分发软件包的内容了。

你理解了这个就能明白,Linux无论是包管理器还是手工下载的安装包,其软件安装过程与Windows和macOS依然是一样的。只不过使用包管理器安装,全程不需要用户手工干预,而使用下载的安装包安装,最多也只需要用户手工进行下载的过程而已。

不过,虽然Linux安装的过程本质上也是在往系统中复制文件,但与另外两个系统不同的是,Linux会把不同职责的文件放到对应职责的文件夹中,而且对于被很多程序共同需要的文件,Linux很可能会把这个文件当作一个单独的程序,就不再附加在其他程序的安装包中了。也就是说,Linux是以文件功能为视角来归类文件而不是以应用来归类,这就使得一个应用的文件会被放到多个文件夹中,且可能需要配合安装其他的一些共有组件包才能让程序正常运行。而这种互相关联的情况,就是平时提到的依赖。

但并不是只有Linux有依赖问题,windows同样存在,只有macOS才近似于没有。而Linux比较明显的原因就在于它把文件归类得太细致了。举个现实中不存在的例子:假如说三大操作系统都有dx组件,且现在需要安装的软件要求系统中有d3dx9_25才能正常运作。那么对于linux来说,我除了要安装这个软件之外,可能还需要另行安装一个名字叫d3dx9_25的软件才能实现运行;而windows虽然也需要安装dx的安装包,但它的dx安装包里边会包括了d3dx9_1至d3dx9_30所有的文件;至于macOS,d3dx9_1至d3dx9_30系列文件可能会直接包括在macOS的操作系统中打包提供,或者直接包括在了程序的安装包中,总之不会要求用户再另行安装一个其他的软件。而假如之后又有一个程序需要使用d3dx9_20,windows由于前一次安装时已经部署了dx系列所有的文件,它就不会再要求额外安装了;但linux还需要再额外安装一个包括了d3dx9_20的软件才能实现运行。由此让用户感觉:哇,Linux依赖问题太麻烦了。

为了不让用户自己解决上面这种额外安装的问题,Linux出现了包管理器这种东西。自然,为了顺应不同的包管理器,就产生了不同格式的软件安装包。但万变不离其宗,安装程序的本质依然是在复制文件进系统,没有太多麻烦的事儿,所以手工部署一个程序是可实现的。相对于包管理器来说,我们要解决的仅仅是如何手工组织文件,以及依赖问题。接下来,就以粤政易为例,实际尝试一下手工安装一个应用程序。

根据私信的描述,粤政易本身提供了.deb形式的安装包,但其使用的archlinux中没有对应的软件包可以使用。因此,唯一的突破口就是官方提供的.deb安装包了。

直接下载deb包,通过归档管理器打开——这个可能是Linux和macOS相对于Windows安装包又一个优势所在:前者的安装包仅仅是一个压缩包,因此可以直接用归档管理器打开查看。

可以看到其中包括的文件,这也是一个Debian安装包的基本构造。我们现在是为了可以手工安装,所以这里直接顾名思义,选择最靠谱的data.tar.xz——数据tarball打开。

如果你使用Linux的话,这两个文件夹应该就眼熟了起来。

这里普及一个可能是冷门的现象:对于粤政易这类国内Linux应用来说,普遍都没有完全遵循Linux的打包思路将文件分别归类,而是有些偏向macOS的风格,将一个应用所有需要的文件都放在了同一个文件夹,然后安装时全释放在/opt的程序文件夹里就算完成了。所以对于粤政易,直接将这个data包里opt中的粤政易拿出来,你便可以开始运行这个程序了,到此,整个手工安装过程也就完成了。

但对于一些较为遵循打包方法的应用,单独解压出来没法使用,怎么办呢?

只需要在程序文件夹执行一个命令:

ldd 二进制文件名

你便会得到一个完整的引导。箭头左边指出了这个应用需要的so文件,箭头右侧则给出了这个so在系统中的具体路径。这时只需要寻找右侧为空的so,来对应安装包含这些so的软件包,补全即可。

到此,无论是什么样的软件包,你应该都通过手工部署完成安装了。

前些日子尝试通过电报来实现短信多终端同步的方案,很成功,并且为了实验稳定性开了一天。到了第二天早晨再看,服务是正常的。但新来的短信就是没再往Tg上面发送。

最先想到的就是梯子有问题了,通过尝试也发现确实是梯子的问题。具体表现就是浏览器会报503错误。

现在使用的是v2ray方法,在刚搭建好的时候也遇到过503问题,所以惯性的认为这次出现这个问题也是由于服务器时间与本地时间不一致导致的(服务器商授时比实际时间快了3分钟,不知道什么毛病)。

不过当我查看服务器时间时候,发现问题好像没那么简单了——因为服务器时间很正常,说明并不是时间出错导致的这个问题——一下子就感觉问题严重了起来。

查看服务状态(systemctl status v2ray),是active,一切如常;查看运行日志(/var/log/v2ray/access.log),一大溜的invalid user。这是认证错误;但是我并没有改过我的config文件(/etc/v2ray/config.json)啊,为什么会失效呢?

上网搜索类似的情况,并没有什么有用的解答。不过在网上冲浪的过程中,v2ray的github页面提交issue的模板让我想到了一个可能的原因:

  • 我的安卓机应用是play商店自动更新的
  • 我的iOS应用是商店自动更新的
  • 我的Archlinux是及时跟进版本的
  • 我的openSUSE刚刚做了一次dup,所有存在新版本的软件都升级到了最新

这些都指向了一个可能的原因:版本不同(github上面就写到了如果客户端和服务端版本不同请注明)。我的客户端全部到了最新而服务端已经很久没有更新过了。

所以先尝试把服务端更新到了最新,再次尝试。

仍然503.

这就真让我百思不得其解了。

不过在查看服务状态时,有一行信息引起了我的注意:它提示读取的配置文件路径是/usr/local/etc/v2ray/config.json

咦?跟网上大多数提到的/etc/v2ray/config.json不一样啊。查看了一下usr的配置文件,里边只有一行:

{}

这就很好的解释了为啥认证会失败了。啥配置都没有,能存在有效用户就怪了。

虽然不知道为什么之前的/etc/v2ray/config.json可以生效,但既然它现在貌似读取的是带usr的路径,那给它补上就得了呗。

不过为了延续之前的路径,做一个软连接可能是更恰当的选择。直接ln -s /etc/v2ray/config.json /usr/local/etc/v2ray——当然,提前把usr那个空的config文件删掉。

尝试重启服务systemctl restart v2ray,查看状态……

退出。

不过下面的信息给出了明确的信息:日志文件无法写入。

那就把日志文件的读写权限给上去就得了呗chmod 666 /var/log/v2ray/*

再次启动服务,成功。尝试通过客户端连接,也成功了。


这问题出现的还挺突然的——因为前一天还是可以正常使用的东西,在啥都没手工动过的情况下就不能用了,还是非常没有头绪去解决的。不过好在没有什么特别令人费解的问题(虽然突然间读取的配置文件路径就变了有些令人费解),很快也就解决掉了。但关键在于网上竟然没有一篇文章能适配到这个问题上,所以还是写下来了。

视频点此

我曾经说过如何在Windows下屏蔽笔记本键盘的教程。现在,来看看Linux下面如何实现屏蔽笔记本键盘。

Linux屏蔽需要安装一个工具xinput。arch系的包名为xorg-xinput,debian系的包名为xinput

之后,通过命令xinput找到自带键盘设备的ID号。这个设备的名字为AT Translated Set 2 Keyboard。找到以这个名字开头的一行,记录后面id=字段的数字。我这里是11.

最后,通过命令xinput set-prop ID 'Device Enabled' 0来完成设备的仅用。其中,ID区域替换为前面找到的数字。

如果想恢复使用,将结尾的0更改为1即可。