在我看来, cron 用法简洁,比一般的 systemd timer 要简单不少,所以,这里记录下我用 cron 时踩过的坑。
有2篇比较不多的文章:
我目前的环境是升级完系统后,需要在它的 /etc/crontab
修改为
SHELL=/bin/bash
基本上可以通过以上的文章了解到 cron 的一些基本用法,这里只是简单的记录我自己在使用过程的一些心得。
vimer@dev:~/check_log$ crontab -l
# 每6个小时的第15min执行一次
# https://www.cnblogs.com/kaituorensheng/p/4494321.html
15,30,45,59 * * * * /bin/bash /home/vimer/check_log/connect_test.sh > /tmp/test.txt 2>&1
其实主要的问题就是 SHELL 环境变量被修改了,直接编辑 /etc/crontab
就可以。
https://etherpad.openeuler.org/p/cron_summary
创建和使用应用专用密码
重要提示:若要创建应用专用密码,您需要为 Google 帐号开启两步验证。
如果您已开启两步验证,并且在登录帐号时收到了“密码不正确”错误消息,可以尝试使用应用专用密码。 前往您的 Google 帐号。
u-boot has their own dtb files (which they periodically sync with the linux tree, see f.e. here)
如果你对本文的内容感觉到唐突的话,可以浏览一下前面的基础铺垫Debian riscv社区过去总结及新年goal和Debian 开发资源列表
2023/07/23是一个很重要的日子,原因在于在这一天,Debian 社区宣布接受riscv64为官方支持的架构,可以说,我们等这一天等了太久了。
从去年这个时候开始,Debian riscv port team就开始推动official port的进程,因为Debian 12 bookworm将会在2023年上半年发布,考虑到种种因素,在当时的条件下,我们认为,这个时间点我们是可以追赶的。2022年5月份 PLCT lab提供了8台Unmatched给Debian RISC-V buildd team使用,这在当时解了RISC-V buildd的构建机不够的燃眉之急,为Debian riscv64 包的状态打下了一个很好的基础。原以为这样就可以顺利的开展下去,谁知道位于Debian 非认可的机房的机器,是不能够进入official port阶段使用的。说到这里,有必须说一下Debian port的一般流程。对于一个新的架构,都是从debian-ports仓库开始的, 简而言之,这个仓库是对于一个新的架构、指令集开始的地方,他可以允许开发者自己搭建的打包机加入到buildd网络中并往debian-ports仓库传包。但是,这个时候,所有的FTBFS( fail to build from source) issue都有port team自己负责,也就是说,包的maintainer是可以拒绝任何与此架构改动的相关patch或者请求,实际实际中大部分maintainer是乐意接受patch的:)。当unofficial port移植到一定程度后,比如满足上面wiki的条件后,才可以继续推动该架构进入official port。
其实一开始我也有误区,任务当时的包从数量上讲已经构建的够好了,为什么还有Debian official port。其实Debian 的official port,就是在Unofficial port的基础上,在Debian 官方DSA维护的打包机重新rebuild的所有的包进行的过程。
buildd正式从DSA掌控的打包机向Debian archive upload 包。
暂时上游还是缺少包:
sudo debootstrap --arch=loong64 --variant=buildd --verbose --include=fakeroot,build-essential --components=main --keyring=/etc/apt/trusted.gpg.d/debian-ports-archive-2023.gpg --resolve-deps --extra-suites=unreleased unstable /home/buildd/build http://ftp.ports.debian.org/debian-ports
注意这里的debootstrap使用,可以使用--extra-suites=unreleased
,但是diy的话这里需要魔改一下。
首先应该看一下这个wiki: https://gist.github.com/F21/b0e8c62c49dfab267ff1d0c6af39ab84
可以根据wiki
通过这个wiki,我们反向理解,并且我加上自己真实案例予以说明。
S老师给我做了一个名为msg.asc
的加密消息,其内容应该就是s老师给我的签名key。
cat msg.asc
-----BEGIN PGP MESSAGE-----
...
...
这就是加密的消息。下面是重点,我们需要使用--decrypt
选项将这个加密消息进行解密:
vimer@dev:~/tmp$ gpg --decrypt msg.asc
gpg: encrypted with 4096-bit RSA key, ID 66681FECEFF9AC75, created 2022-04-09
"Bo YU <[email protected]>"
...
Hi,
please find attached the user id
Bo YU <[email protected]>
of your key 954E6A70100598A2 signed by me.
If you have multiple user ids, I sent the signature for each user id
separately to that user id's associated email address. You can import
the signatures by running each through `gpg --import`.
Note that I did not upload your key to any keyservers. If you want this
new signature to be available to others, please upload it yourself.
With GnuPG this can be done using
gpg --keyserver hkp://pool.sks-keyservers.net --send-key 954E6A70100598A2
...
------------=_1689674421-10093-0
Content-Type: application/pgp-keys;
name="0x954E6A70100598A2.1.signed-by-0xxxxxxxx.asc"
Content-Disposition: attachment;
filename="0x954E6A70100598A2.1.signed-by-0xxxxxx.asc"
Content-Transfer-Encoding: 7bit
Content-Description: PGP Key 0x954E6A70100598A2, uid Bo YU <[email protected]>
(1), signed by 0xxxxxxxxxxx
-----BEGIN PGP PUBLIC KEY BLOCK-----
...
-----END PGP PUBLIC KEY BLOCK-----
注意,这个PUBLIC KEY BLOCK
的内容才是最重要的内容,我的做法是copy出来保存到一个xx.asc文件,然后再 import
.
vimer@dev:~/tmp$ gpg --import sun.asc
gpg: key 954E6A70100598A2: 1 signature not checked due to a missing key
gpg: key 954E6A70100598A2: "Bo YU <[email protected]>" 1 new signature
gpg: Total number processed: 1
gpg: new signatures: 1
gpg: marginals needed: 3 completes needed: 1 trust model: pgp
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
vimer@dev:~/tmp$ gpg --keyserver keyserver.ubuntu.com --send-keys 100598A2
gpg: sending key 954E6A70100598A2 to hkp://keyserver.ubuntu.com