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>"

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

参考链接


运维中tcp_tw_recycle net.ipv4.tcp_timestamps引发的坑

NAT环境下,遇到因为tcp_tw_recycle=1和net.ipv4.tcp_timestamps=1引起 Nginx upstream timed out 后,一直没在遇见,今天在朋友的阿里云环境下又重新再一次出现;因此在这炒一次冷饭,让运维新手或者刚上云的朋友大概了解一下,避免再一次采坑。

故障情况:

阿里云账号A的A机房,内网里面部署两台Nginx,通过网络出口(NAT),代理用户访问到阿里云账号B的B机房服务。A机房的Nginx出现:upstream timed out 。

故障的诱因是:net.ipv4.tcp_timestamps=1

抓包图:

注意,这个选项生效的前提是,报文的发出方必须在TCP头部的可选项中增加时间戳字段,否则这个设置是不生效的。

直接上当年的笔记:

先看看TCP IP 对tw的一些解析:
RFC 1323里有这样的定义:

大概的中文意思就是:TCP协议中有一种机制,缓存了每个主机(即ip)过来的连接最新的timestamp值。这个缓存的值可以用于PAWS(Protect Against Wrapped Sequence numbers,是一个简单的防止重复报文的机制)中,来丢弃当前连接中可能的旧的重复报文。而Linux实现这个机制的方法就是同时启用net.ipv4.tcp_timestamps和net.ipv4.tcp_tw_recycle 这两个选项。
这种机制在 客户端-服务器 一对一的时候,没有任何问题,但是当服务器在负载均衡器后面时,由于负载均衡器不会修改包内部的timestamp值,而互联网上的机器又不可能保持时间的一致性,再加上负载均衡是会重复多次使用同一个tcp端口向内部服务器发起连接的,就会导致什么情况呢:

负载均衡通过某个端口向内部的某台服务器发起连接,源地址为负载均衡的内部地址——同一假如恰巧先后两次连接源端口相同,这台服务器先后收到两个包,第一个包的timestamp被服务器保存着,第二个包又来了,一对比,发现第二个包的timestamp比第一个还老——客户端时间不一致。服务器基于PAWS,判断第二个包是重复报文,丢弃之。

反映出来的情况就是在服务器上抓包,发现有SYN包,但服务器就是不回ACK包,因为SYN包已经被丢弃了。为了验证这一结果,可以执行netstat -s | grep timestamp 命令,看输出里面passive connections rejected by timestamp 一项的数字变化。

tcp_ipv4.c中,在接收SYN之前,如果符合如下两个条件,需要检查peer是不是proven,即per-host PAWS检查:

  • 收到的报文有TCP option timestamp时间戳
  • 本机开启了内核参数net.ipv4.tcp_tw_recycle

解决办法:

tcp_tw_recycle=0 或(和)net.ipv4.tcp_timestamps=0同时从4.10内核开始,官方修改了时间戳的生成机制,所以导致 tcp_tw_recycle 和新时间戳机制工作在一起不那么友好,同时 tcp_tw_recycle 帮助也不那么的大。

此处的时间戳并不是我们通常意义上面的绝对时间,而是一个相对时间。很多情况下,我们是没法保证时间戳单调递增的,比如业务服务器之前部署了NAT,LVS等情况。相信很多小伙伴上班的公司大概率实用实用各种公有云,而各种公有云的 LVS 网关都是 FullNAT 。所以可能导致在高并发的情况下,莫名其妙的 TCP 建联不是那么顺畅或者丢连接。

而这也是很多优化文章中并没有提及的一点,大部分文章都是简单的推荐将net.ipv4.tcp_tw_recycle设置为1,却忽略了该选项的局限性,最终造成严重的后果(比如我们之前就遇到过部署在nat后端的业务网站有的用户访问没有问题,但有的用户就是打不开网页)。

参考链接


certbot-auto不再支持所有的操作系统,新的ssl证书方法

最近在一台服务器执行letsencrypt-auto命令出现错误:

系统不再被支持!!!

查看certbot(https://github.com/certbot/certbot/releases)

2021年1月的更新日志:

可知:

certbot-auto不再支持所有的操作系统!根据作者的说法,certbot团队认为维护certbot-auto在几乎所有流行的UNIX系统以及各种环境上的正常运行是一项繁重的工作,加之certbot-auto是基于python 2编写的,而python 2即将寿终正寝,将certbot-auto迁移至python 3需要大量工作,这非常困难,因此团队决定放弃certbot-auto的维护。

既然如此,现在我们还能继续使用certbot吗?certbot团队使用了基于snap的新的分发方法。

1. 环境
操作系统:CentOS 7

Webserver:Nginx

2. 安装letsencrypt
2.1. 安装letsencrypt之前,需要先安装snaps

a. 先安装epel

b. 安装snapd

c. 启用snapd.socket

d. 创建/var/lib/snapd/snap/snap之间的链接。

e. 退出账号并重新登录,或者重启系统,确保snap启用。

f. 将snap更新至最新版本。

2.2. 卸载已安装的certbot

如果之前在系统上已经部署过certbot,则需要先将其进行卸载。

a. 卸载certbot

b. 根据certbot安装位置删除相关文件。

c. 删除certbot附加软件包。

2.3. 安装certbot

a. 通过snap安装certbot

b. 创建/snap/bin/certbot的软链接,方便certbot命令的使用。

3. letsencrypt的使用
3.1. 获取证书。

a. 生成证书。

确保nginx处于运行状态,需要获取证书的站点在80端口,并且可以正常访问。

b. 更新nginx配置并重启nginx

3.2. 更新证书。

ubuntu系统的话,使用如下命令方式安装:

参考链接


certbot-auto不再支持所有的操作系统,新的ssl证书方法

Centos 设置httpd-2.2 or httpd-2.4 MPM模式

MPM多进程处理模块

MPM分为三种模式:

1,prefork

进程模型,每个进程处理一个请求,模式:父进程——————>多个子进程——————>一个子进程处理一个请求

2,worker

线程模型,每个进程衍生出多个线程,每个线程处理一个请求,模式:父进程——————>多个子进程——————>每个子进程衍生多个线程------->一个线程处理一个请求任务

3,event

事件驱动模型,一个进程处理多个任务,模式:父进程————————>多个子进程-------->一个子进程处理多个请求

centos6 httpd-2.2 MPM设置

修改文件

/etc/sysconfig/httpd

默认为prefork模式

配置后重启httpd server生效

centos7 httpd-2.4 MPM设置

修改文件 /etc/httpd/conf.modules.d/00-mpm.conf

模式参数配置详解

参考链接


Centos 设置httpd-2.2 or httpd-2.4 MPM模式