分类 Linux 下的文章

视频点此

曾经有一个半个钟头的视频,大概演示了一下如何在Optimus模式的笔记本电脑上实现英伟达显卡的虚拟机直通,后来又用了一个视频简单说了说如何在Linux中安装KVM虚拟机以及一个简单的图形界面。不过得益于KVM虚拟机在Linux上面的优异表现,KVM虚拟机的图形界面程序也算是层出不穷。这其中不乏观感不错、使用简单的图形界面程序。今天就来看一个,我认为可以当作是virtual box平替的KVM图形界面程序——Quickgui

简单来说,quickgui是quickemu和quickget的一个图形化前端,而quickemu是简化qemu建立KVM虚拟机的一个终端脚本。因此与virt-manager等KVM图形化管理器差异的地方,在于quickgui侧重于帮助用户根据选择的系统和自身电脑的配置一键配置好一个可用的KVM虚拟机,并统一管理已经建立的KVM机器。在这个过程中甚至不需要用户事先准备安装镜像文件。那么接下来就看看如何安装。

就像前面说的,quickgui是quickemu和quickget的前端,因此首先需要安装好这两个。前往quickemu的github,可以看到对于arch用户,可以通过aur直接安装,而乌班图用户则可以添加它的ppa并完成安装。但我现在用的是opensuse,就需要手工来安装了。

在quickemu的页面里写了所需的依赖,其中要求QEMU版本需要在6.0或更高。但openSUSE官方源中,其版本刚刚到达5.3,所以首先需要做的就是升级QEMU。

  1. 直接打开终端,输入opi qemu,在弹出的源列表中选择Kernel:tools,然后按照提示更新提供方,完成。
  2. 打开YaST的软件管理模块,切换到模组标签,找到KVM主机服务器,将右侧打勾的版本全部切换到刚刚添加的源上(如有),确定。

到此,QEMU版本的升级就完成了。

如果你是全新安装的openSUSE,可能还有一些依赖需要你去补齐。可以按照github的指引进行安装,或者先按照下述步骤安装好quickemu与quickget尝试运行,失败的话再查看依赖问题。

  1. 克隆quickemu到一个文件夹:git clone --depth=1 https://github.com/wimpysworld/quickemu
  2. 全局安装quickemu到系统:sudo update-alternatives --install /usr/local/bin/quickemu quickemu /path/to/quickemu 50,其中,/path/to/quickemu为刚刚保存了克隆工程的文件夹,其中可以找到quickemu这个脚本
  3. 将quickget全局安装到系统,命令同2,只是将所有的quickemu更改为quickget

到此,你应该可以直接在终端中使用命令quickemuquickget来直接调用这两个脚本而无需再进入到保存的文件夹中执行了。这也意味着我们已经建立好quickgui所需的基本环境了。接下来就是安装quickgui

  • 前往quickgui的github,下载最新发布的预编译包,解压到某个目录下

进入这个目录,双击quickgui,一个好看的管理界面就正常启动了。

它的功能非常简单:管理已有的机器与建立新机器。初次使用时,可以通过新建机器功能快速建立一个KVM虚拟机。而且这个建立只需要我们选择好需要的操作系统版本和保存路径,点击下载,软件便会自动下载并部署好,等待启动。待下载完成,切换到管理已有机器的界面,便可以看到刚刚创建的虚拟机了。

管理界面也很简洁,只有三个可以操作的功能:启动、停止、删除。如果你是arch 或者乌班图用户,此时应该可以通过启动按钮直接简单的打开这个虚拟机了。但对于openSUSE,你会发现无法正常显示虚拟机窗口,再等待一会儿就恢复到了启动前的状态了。这是为什么呢?

因为openSUSE的QEMU默认不到有fd文件——KVM的efi程序,同时已经不再支持sdl模式运行。所以我们需要针对这两个进行调整。

首先,补全fd文件。

  1. 前往https://www.kraxel.org/repos/jenkins/edk2/下载对应你的电脑架构的rpm包
  2. 无需安装,直接找到其中保存了fd文件的文件夹,将这堆fd文件解压到/usr/share/qemu
  3. 将其中的ovmf_VARS-pure-efi.fd重命名为ovmf_VARS.fd

到此,fd文件我们就补齐了。

当然,只从rpm包中解压出ovmf_VARS-prue-efi.fd也是可行的。这里全部解压只是为了方便而已,也为了避免之后特殊需要时候再次补充。

对于sdl支持,我尚未找到什么好的解决方法,所以我目前的方式就是通过终端来启动构建好的虚拟机。

  1. 进入到创建虚拟机时选择的保存路径,应该可以看到对应这个虚拟机的conf文件
  2. 使用命令启动虚拟机:quickemu --vm 配置文件.conf --display gtk

到此,我们便成功构建并打开一个KVM虚拟机了。

视频点此

这一晃,上班都一年半了,我所有的电脑——除了MacBook——就像我之前那个讨论archlinux与opensuse的视频里所说的那样,全都上到opensuse了。不仅如此,还陆陆续续的“维护”了一些我自己用到了,但尚没有人在opensuse的源中提供的软件。在这个过程中,Leap也从15.2过渡到了15.3。虽然版本号只提了0.1,但其变化是异常巨大的。但今天,我不细说它的变化,而是来谈谈我自己认为安装好15.3后必须做的几件事儿。

首先,禁用debug和source源。我只是一个普普通通的用户,并不会debug,也不关心程序代码。所以这两个源对我来说是毫无用处的。因此首先就把这两个源给禁用掉。直接前往YaST的软件源模块,将所有debug和source条目的自动刷新和启用勾选去掉即可。

在这里,你也许就会看到一个奇特的地方:相同名字的源会有两个,其中一个带有update标记。其实就是你想的那样,openSUSE把源分成了基本和更新两类。其中,基础源是不会很频繁的更新的,所有组件的更新全部通过update源来提供。因此自动刷新基础源是没有什么意义的。所以,还是在软件源这个模块,将基础源的自动刷新关闭。

到这里,对源的优化就算是完成了。

由于SUSE是实体组织的原因,很多专有软件无法直接通过这些源来提供,因此很多时候我们需要通过一个叫做packman的源来安装。但经过这段时间的使用下来,我发现packman包含的软件数量还是比不了其他发行版——可能是我使用的软件比较刁钻?所以我更多的会使用obs源来安装这些软件。obs提供浏览器版本的安装途径,但总是莫名其妙的搜不到想要的内容,所以想要完美使用obs的软件,还是借助一类似aur助手的终端工具:opi。直接通过YaST的软件管理工具安装即可。

准备工作做好,接下来就是一些我自己需要的基础组件了。首先,与其他非实体组织发布的发行版不同的地方在于SUSE初始不会带有专有解码器,默认情况下不能播放常见的音视频。因此首先就要安装解码器。还是在软件管理,打开到视图—源—packman,点击修改软件包版本到packman,确认即可。

我自己依然需要英伟达的专有驱动。因此回到软件源模块—添加—社区软件源—nVidia Graphics Drivers—确定。待刷新后前往软件管理,会自动勾选出需要的驱动,直接确定等待完成即可。如果没有自动选择,直接搜索nvidia,选择适合自己的x11-video-nvidiaGxx安装即可。一般使用G05应该不会出什么意外。

为了实现简单的双显卡切换,直接安装suse自己的切换模块suse-prime以及托盘程序suseprime indicator。如此我们便可以方便的在托盘右键来选择使用哪一块显卡了。

最后,由于我跨越三大操作系统在使用,所以我的移动存储设备全都是exfat格式的,但suse不会自带这个格式的驱动。因此额外再安装exfat-fuse,到此一个openSUSE便完全方便日常使用了。

视频点此

如果你需要在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的软件包,补全即可。

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

视频点此

可能你想不到,我一直订阅着个人版的Office365,所以我拥有1T的onedrive存储空间。说实话,我一直想不到这么大的空间能用来干啥,直到我看到了我这个树莓派做的局域网文件中心。
为何不外挂上onedrive,整一个异地备份呢?

实现这个系统的关键其实就有一点:在树莓派上安装onedrive。我尝试过一些开源onedrive程序,但要么不支持arm架构,要么安装很繁琐。所以最终我跳出了花里鼓哨的onedrive客户端,转向了rclone——一个支持将很多协议映射成本地目录的神奇的软件。直接从源中安装即可。

安装好后,输入命令rclone authorize “onedrive”,会打开浏览器进入登录界面,登录成功后终端会返回token,保存好。

接下来,通过命令rclone config来根据向导进行配置,按照提示输入操作即可。只需注意最开始要输入一个名称,这个名称指代了网络硬盘,以后挂载时会使用到这个名字,所以要记住。同时,不需要选择高级设置,以及在最后登录一步的时候选择手动配置,将刚刚保存的token完全复制到终端即可。

现在,就可以通过命令rclone mount 名字: 挂载点 —daemon把你的onedrive挂载到本地了。这个挂载点完全指向了onedrive的目录,任何复制到这里的文件都将被直接上传到onedrive中。换句话说,复制进这个文件夹的文件将不再占用本地的磁盘空间,而是直接进入到onedrive之中。

测试无误后,我们将这条命令设置为开机启动。但是我发现通常方法,也就是在rc.local中加入语句并不能实现开机自启,所以这里也介绍一下设置开机启动的方法。

~/.config下新建autostart文件夹,其中新建一个.desktop文件,文件名随意。其中输入如下文本。

[Desktop Entry] 
Type=Application 
Exec=lxterminal -e “刚才那一串挂载指令”
Name=随便一个名字
Comment=随便一些注释

这就为rclone挂载命令建立了一个自动启动文件。以后无论何时启动树莓派,rclone都会把onedrive挂载到指定的文件夹中。受到一些小伙伴的提示,如此自启动可能只有把树莓派设置为使用gui且自动登录时候才会生效。要注意。

之后进行双向同步操作。我这里直接简单粗暴的通过计划任务加bash脚本来实现,一个负责从本地拷贝到远程(也就是挂载了onedrive的那个文件夹),一个负责从远程拷贝回本地。而本地目录是一个特定的目录,所有想同步到onedrive上的文件夹通过软链接的方式放到这个文件夹中。

到此,我的这个双点同步系统就搭建完成了。

相关视频:OBSAUR

这个文章只是简要介绍一下使用OBS构建软件包的基本方法,以及AUR与OBS在编写时候的对应关系。编写一个规范且更易维护的软件包要比这里边提到的关注点要多。

一、什么是OBS

开放构建服务Open Build Service)是一个通用的系统,以自动、连贯和可重复的方式从源代码构建和分发软件包。它可以为各种操作系统和硬件架构发布软件。我们用来构建发行版的 OBS 参考服务器目前(2018 年 6 月)已有 53219 个项目,其中包含了 79794 个仓库中的 468316 个软件包,用于众多发行版和架构,并由 53171 个已确认的开发者使用。

资料来源于Portal:构建服务 - openSUSE Wiki

二、什么是AUR

Arch 用户软件仓库(Arch User Repository,AUR)是为用户而建、由用户主导的 Arch 软件仓库。AUR 中的软件包以软件包生成脚本(PKGBUILD))的形式提供,用户自己通过 makepkg) 生成包,再由 pacman) 安装。创建 AUR 的初衷是方便用户维护和分享新软件包,并由官方定期从中挑选软件包进入 community 仓库。许多官方仓库软件包都来自 AUR。通过 AUR,大家相互分享新的软件包生成脚本(PKGBUILD) 和其他相关文件)。用户还可以为软件包投票。如果一个软件包投票足够多、没有协议问题、打包质量好,那么它就很有希望被收录进官方 community 仓库(以后就可以直接通过 pacmanabs 安装了)。

资料来源于Arch User Repository(简体中文)

三、快速通过OBS构建一个软件包

以我打包的electron-wechat为例。

一切的基础,是需要你拥有一个OBS账号并登录。前往OBS官网注册并登录,你就拥有你的工作空间了。

通过Create Package,来创建一个软件包目录,并将源码上传到这个目录中。但要注意的是,OBS构建的服务器是不联网的,所以对于electron-wechat这种nodejs的程序,由于通过npm命令进行构建的时候一定会去往nodejs官网检索相关依赖的最新版本,所以对于这种程序,最简单的办法就是直接上传编译好的文件进行分发。


这里想补充一下:已经在自己的电脑上编译好了,那就已经可以使用了,为啥还要使用OBS打包呢?很简单,因为自己编译出来的东西是零散的,需要手工把文件放到对应的位置上去,而且没有一个统一的卸载方法。通过OBS打包之后,就可以进入到软件源中,直接通过统一的安装/卸载指令来使用一个软件了。


所以对于electron-wechat,我就是在本地编译好了之后,将二进制文件打包成tar.bz2,上传到了打包目录。

之后,编写spec文件。这个文件告诉了OBS到底都需要干什么来完成打包。

在打包目录下新建软件包名.spec,开始填空。(如果使用openSUSE的vi编辑器直接新建的话,会直接生成一个.spec文件的模板,填空即可。)

  • Name: 软件包名
  • Version: 软件包版本
  • Release: 使用默认即可
  • Summary: 一句话介绍
  • License: 许可证类型
  • Group: 软件类别
  • Url: 项目地址
  • Source: 源码地址

    如果有多个源码,可以通过Source0 Source1 依次指定。参考我打包的dingtalk

  • Provides: 提供的内容
  • Obsoletes: 排斥的内容

然后,在%description下写一个比较详细的软件介绍,不主要的部分就写完了。

之后,%prep下写入打包要做的准备工作。比如解压缩源码包。对于以软件包名-版本号.tar.bz2形式的包,默认的%setup -q即可完成解压。其他命名方法的bz2,需要补充 -n 参数。即setup -q -n 包名

如果还有其他要解压之类的工作,一并写在这个下面,可以参考rpm打包的宏,如果不熟悉,也可以使用bash命令代替。

准备工作做好,填写%build编译部分。对于一般的C语言,可以上传源码包,在%build填写编译的指令。而对于nodejs这种无法通过编译的软件,由于上传的就是编译好的二进制文件,所以编译这部分留空。

%install指示了编译出来的所有文件都要放到什么地方。这里相对比较简单理解,就是通过bash命令,把编译出来的文件依次复制到它应该在的位置即可。至于具体应该在什么位置,就要看一看Linux的标准了。如果不确定的话,把所有文件放在/opt/软件名这个文件夹下也未尝不可。这种做法并不标准,但很快。不过即使如此操作,也需要注意desktop桌面入口文件和图标文件一定要放置在它应该在的位置,否则在图形界面一定会找不到启动的按钮,图标显示也会有问题。
%post -p /sbin/ldconfig%postun -p /sbin/ldconfig两句话照抄即可。

之后,在%files下书写这个软件都拥有哪些文件和文件夹。宗旨就是产生了哪些文件,就把绝对路径写在这里。

到此,一个简易的spec文件就写好了。

之后的查错,可以通过OBS编译结果进行排查,根据报错进行修改即可。

四、AUR编写与OBS的异同

AUR与OBS非常类似,区别只在于OBS的spec文件命名是根据软件包名命名的,而AUR的文件叫做PKGBUILD。所以在AUR建立一个软件工程后,直接新建一个PKGBUILD,在里边编写即可。

至于编写的内容,与OBS也很类似,只不过AUR是一个更纯粹的脚本,不能使用OBS里边诸如%prep这种宏来书写。

我的OBS仓库的dingtalk就是借鉴AUR的dingtalk-linux。可以对比着来看一看。

相对来说,AUR的编写更容易上手,但是相对OBS来说,编写出来的PKGBUILD通用性会差一些。不过无论哪种,思路都是类似的。看一看现有的文件写法,自己尝试一下就会了。