使用SSH Key访问服务器

1. 配置

生成的 SSH Key 默认存储在 ~/.ssh 目录下,可以使用 ls ~/.ssh 查看之前是否已经生成过 SSH Key,如果提示 No such file or directory 可以使用如下指令用于生成 SSH Key:

接着会询问保存文件的位置以及是否要设定 passphrase,如果设定了 passsphrase 那么每次使用该 SSH Key 的时候都需要输入这个 passsphrase,可以根据自己对安全性的需求设定,空白表示不设定。

如果采用默认的设置,那么会在 ~/.ssh 路径下生成两个 Key,一个私钥 id_rsa ,另一个公钥 id_rsa.pub,私钥需要好好保管。

2. 使用 ssh-copy-id

如果操作系统中有 ssh-copy-id,那么可以直接使用以下命令设置:

  • username:连接服务器的用户名
  • server:服务器的域名或者 ip 地址
  • ~/.ssh/id_rsa.pub:默认的公钥地址,如果修改过 SSH Key 存储地址,请填写对应地址

3. 复制公钥到服务器的 authorized_keys 中

上述命令用于在远程服务器上创建 ~/.ssh 文件夹并用本机的公钥创建服务器上的 ~/.ssh/authorized_keys 文件,接着设置权限:

4. 验证

经过上述的配置之后,可以再次进行 SSH 连接验证配置是否生效:

如果不需要输入密码就能够连接服务器,说明设置生效。

参考链接


使用 SSH Key 访问服务器

Ubuntu 22.04 (x64)树莓派4B(Raspberry Pi 4B)源代码编译

树莓派上的操作


树莓派使用的系统是通过 Raspberry Pi Imager 安装的 2023-05-03-raspios-bullseye-armhf.img.xz

1.升级到最新版内核保证与下载的内核源码版本一致

2.升级完整后重启

3.查看内核版本

4.把最新版本的内核配置保存到.config中,以备以后编译内核使用

文件被存储到了/proc/config.gz中。

目前最新版本是 6.1.12,当前内核启动默认会切换到 64位内核了,即使安装的是32位系统镜像也是这样。

如果想从32位内核启动,那么需要在 config.txt 中配置 arm_64bit

继续阅读Ubuntu 22.04 (x64)树莓派4B(Raspberry Pi 4B)源代码编译

多线程压缩工具pigz使用

学习Linux系统时都会学习这么几个压缩工具:gzip、bzip2、zip、xz,以及相关的解压工具。关于这几个工具的使用和相互之间的压缩比以及压缩时间对比可以看:Linux中归档压缩工具学习

那么Pigz是什么呢?简单的说,就是支持并行压缩的gzip。Pigz默认用当前逻辑cpu个数来并发压缩,无法检测个数的话,则默认并发8个线程,也可以使用-p指定线程数。需要注意的是其CPU使用比较高。

官网:http://zlib.net/pigz

安装

使用方法

原目录大小:

接下来我们分别使用gzip以及不同线程数的pigz对h19_index目录进行压缩,比较其运行时间。

各个压缩时间的比较:

程序 线程数 时间
gzip 1 5m28.824s
pigz 4 1m18.236s
pigz 8 0m42.670s
pigz 16 0m23.643s
pigz 32 0m17.523s

从上面可以看出,使用多线程pigz进行压缩能进行大大的缩短压缩时间,特别是从单线程的gzip到4线程的pigz压缩时间缩短了4倍,继续加多线程数,压缩时间减少逐渐不那么明显。
虽然pigz能大幅度的缩短运行时间,但这是以牺牲cpu为代价的,所以对于cpu使用较高的场景不太宜使用较高的线程数,一般而言使用4线程或8线程较为合适。

参考链接


多线程压缩工具pigz使用

Flutter The Linux toolchain CMake build dependency (CMake 3.14 or higher is required. You are running version 3.10.2)

ubuntu 22.04 通过 snap 安装了 Flutter SDK(当前是Flutter 3.3.4),如果第三方的依赖了 CMake 3.10.2 更高的版本,会在编译的时候报错:

这个报错的原因是由于 snap 安装的 Flutter SDK 构建了一个沙箱环境,在这个环境中的 CMake3.10.2 版本,不管系统安装的是哪个版本的 CMake ,都是无效的。

要解决这个问题,或者等待 snapFlutter SDK 更新版本,或者参照 Linux install Flutter 的说明,手工安装并配置 Flutter SDK

可以参考如下代码:

参考链接


Flutter 3.0实现Linux本地化/国际化

参照 Flutter 2.8.1本地化/国际化应用程序名称 可以实现 Android/macOS/iOS/Web 的应用名称相关的国际化。但是在 Linux 应用上如何相同的功能,目前暂时没有一个统一的标准。

研究了许久,终于基本上算是搞定,解决方案如下:

使用 gettext 来实现国际化相关的功能。

首先配置,调整工程的目录如下:

project/
project/linux
project/linux/flutter
project/linux/flutter/CMakeLists.txt
project/linux/locale/en_US/app.po
project/linux/locale/zh_CN/app.mo
project/linux/locale/CMakeLists.txt
project/linux/CMakeLists.txt
project/linux/main.cc
project/linux/my_application.cc
project/linux/my_application.h

对应语言 i18n 相关配置文件的内容如下:

接下来,修改 Linux 工程的配置文件,增加对 本地化(i18n) 文件的引用,在合适的位置增加如下代码:

完整的代码参考如下:

使用多语言的代码如下:

参考链接


ubuntu 20.04升级到ubuntu 22.04报错“update-alternatives: 错误: /var/lib/dpkg/alternatives/mpi 损坏:次要链接与主链接 /usr/bin/mpicc 相同”

ubuntu 20.04 升级到 ubuntu 22.04 报错,报错内容如下:

解决方法:

Flutter构建Linux应用

从3.0之后的版本,flutter已经正式支持构建Linux应用

条件

  • ubuntu 22.04
  • Android Studio Chipmunk |  2021.2.1
  • flutter sdk 3.x

方法

1. 打开Linux的平台支持

输入如下指令(如下命令可以使用flutter config查看,2.10以上的版本默认开启

可以使用flutter doctor查看情况。

安装编译依赖

2. 在旧项目中添加Linux平台支持

在项目地址输入如下指令

注意: 项目的名称必须是全小写,如果出现大小写则会报错

3. 构建Linux项目

4. 报错

出现这个问题

参考链接


SSH默认不支持RSA了

今天升级ubuntu 22.04/Window 11后最基本的ssh登陆突然出问题了, 提示有几种:

一查发现…好嘛, openssh觉得ssh-rsa加密方式不安全, 直接从8.8开始默认不允许这种密钥用于登陆了

解决方法是可以在~/.ssh/config里面加这么一段解决:

第一行说明对所有主机生效, 第二行是将 ssh-rsa 加会允许使用的范围, 第三行是指定所有主机使用的都是 ssh-rsa 算法的key

实测两行都得要写才行, 没有第二行提示没有 ssh-rsa 这么个类型

没有第三行就提示 sign_and_send_pubkey: no mutual signature supported

参考链接


ssh默认不支持rsa了

polkit的pkexec中的本地权限提升漏洞 (CVE-2021-4034)

漏洞简介

漏洞编号: CVE-2021-4034

漏洞产品: PolKit (pkexec)

影响版本: 影响2009年 - 今的版本(当前0.105)

源码获取:

​ 或 https://launchpad.net/ubuntu/bionic/+package/policykit-1

继续阅读polkit的pkexec中的本地权限提升漏洞 (CVE-2021-4034)

How to repair a broken/unmountable btrfs filesystem

最近磁盘上的Btrfs分区在调整大小的时候,报错:

How to repair a broken/unmountable btrfs filesystem

The below are the recommended steps for any major btrfs filesystem issue, especially if its unmountable. Reading dmesg or syslog might help you identify which step you could skip to in order to fix a particular problem, but the initial steps are normally useful regardless as btrfs scrub is a very safe repair tool.

  • Boot to a suitable alternative system, such as a rescue shell, different installation of openSUSE, a liveCD, or an openSUSE installation DVD. The installation DVD for the version of openSUSE you are running is usually a good choice as it will certainly use the same kernel/btrfs version. A recent Tumbleweed disk might be better as it will include newer kernel/btrfs
  • Go to a suitable console and make sure you do the below as root
  • Try to mount your partition to /mnt, just to confirm it's really broken

  • If it mounts - are you sure it's broken? if Yes - run

to scrub the system, and

to monitor it

  • If it doesn't mount, try to scrub the device just in case it works

and

to monitor. Once complete, try mounting, if yes, you're fixed.

  • If scrubbing is not an option or does not resolve the issue

then instead try mount -o usebackuproot

Warning: All of the above steps are considered safe and should make no destructive changes to disk. If the above doesn't fix things for you, you can continue with the below steps but the situation is serious enough to justify a bug report, please!

  • Run "btrfs check <device>"

This isn't going to help, but save the log somewhere, it will be useful for the bug report.

  • Seriously consider running "btrfs restore <device> <somewhereto copy data>"

This won't fix anything but it will scan the filesystem and recover everything it can to the mounted device. This especially useful if your btrfs issues are actually caused by failing hardware and not btrfs fault.

  • Run "btrfs rescue super-recover <device>"

Then try to mount the device normally. If it works, stop going.

  • Run "btrfs rescue zero-log <device>"

Then try to mount the device normally. If it works, stop going.

  • Run "btrfs rescue chunk-recover <device>"

This will take a LONG while. Then try to mount the device normally. If it works, stop going.

  • If you didn't run it earlier, be sure to now run "btrfs restore <device> <somewhere to copy data>"

  • Failure to use btrfs restore at this point but continuing to attempt repairs means you are at a very high risk of data loss. It is advisable to use btrfs restore to recover as much data as possible before continuing.

Warning: The above tools had a small chance of making unwelcome changes. Below this point there is a higher risk of damage. Do not continue unless you're prepared to accept the consequences of your choice.

  • Now, ONLY NOW, try btrfsck aka "btrfs check --repair <device>"

最后,上面的步骤都不能解决问题,因此最终是把磁盘上的文件全部拷贝出来,然后重新格式化分区,再把文件全部拷贝回去,解决问题。

参考链接