0%

在查看项目时,发现一些项目尤其后端项目有个Makefile文件,这样一些构建命令可以方便的封装调用。

之前没了解过该工具,这里mark下。

特点

  1. Mac/Linux天然支持,这样声明创建后,直接执行即可
    • shell文件的话,还需手动增加执行权限chmod +x *.sh
    • 项目中使用nodejs实现构建工具也行,但是毕竟还有环境依赖
  2. 支持变量传参

举个例子

1
2
3
# 构建前端镜像 make build version=1.0.0
build:
docker build -t stacker/web:v$(version) .

比如封装如上命令到Makefile,以后想打包新镜像文件,直接make build version=1.0.0即可

语法说明

  • 文件名推荐为Makefile,但也可以是makefile
  • 只支持单行注释
  • @开头命令声明,表示该命令输出结果不打印

参考配置

  1. https://gitlab.com/gnachman/iterm2/-/blob/master/Makefile

306医院-皮肤科治疗不理想,因此选择换到了北大人民医院,相对觉得还是强些的,但也遇到了很多麻烦事,比如流程,这里mark下。

携带物品

  • 社保卡-第一次需要开通该医院电子医保需要,之后不需要
  • 手机-挂号,支付等

就医全流程

  1. 微信114挂号-注意不是小程序
    • 每个医生出诊时间不同,推荐还是维持找同一个医生,避免啰嗦嘴皮子说病情,即使就诊信息上都有记录。比如我目前觉得不错的医生是周二周三出诊,因此我就挂这两天的号。
  2. 进入医院时扫码填写防疫信息
  3. 门口左侧自助取号机取号,推荐使用手机-支付宝-电子医保支付
  4. 门诊楼就诊-皮肤科在4楼,扫码签到等待叫号
  5. 就诊后,在4楼或者其它楼层均可直接自助机支付药费
  6. 根据药品情况去一楼或者四楼取药
  7. 由于需要走商业保险报销,因此需要发票,而医院不提供电子发票,所以只能在人工支付窗口排队,打印发票,有时需要提醒医生挂号费也打印下发票

个人觉得不合理的地方

  1. 医院门口取号机器有些不能用了,没有任何提示,因此在真正取号时,只要觉得有问题,直接找人问,别在那一直试,白浪费时间。
  2. 皮肤科取药的队伍是跟治疗的一个排队,造成前面可能非常慢,白浪费时间,这时建议直接找门诊医生说让她安排人进去拿药吧,几分钟的事,在那排个把小时,纯粹浪费。
  3. 不同医院间就诊信息不同步,因此比如在A医院做过的检查在B医院不认,无端造成浪费,因此建议就诊的话,维持一个医院不变好些。

总而言之

  1. 对比306医院皮肤科,北大人民医院的更专业些,因此最近该病的治疗一直在该医院了。
  2. 医院看病总能看到很多不合理的地方,尽可能采取各种手段为自己节约时间吧。

Alfred除了Mac版之外,对于iPhone/iPad也有移动App版,经过一段时间使用,这里将个人的实践总结下

推荐入手?

先说结论

  1. remote本身只是桌面版Alfred的延伸,本质还是操作了Mac版Alfred,因此可玩性有,只是还比较鸡肋
  2. 如果没有远程控制Mac的场景,个人不建议购买,毕竟并不常用

有需求的继续👇

下载/资费

  • 付费/4.99刀,国区有上架,不需要走外区,下载地址
  • 未提供Android版,且作者无计划支持
  • remote使用并不要求Mac版必须购买了powerpack license,但想通过workflow trigger实现复杂功能的话,还是需要购买为好,因此非powerpack用户,remote可玩性不高

定位

The ultimate iOS command centre for Alfred. Your iPhone or iPad now becomes a perfect day-long companion to your Mac.

官网介绍如上,可以了解到,Alfred remote定位是Mac版Alfred的控制中心,借由remote操作桌面版Alfred下的命令/workflow,从而实现Mac的远程操作。

局限性

  1. 当前Alfred Remote没有支持同步Mac系统剪贴板,做到iOS上也有剪贴板历史支持

使用

配置

  1. Mac版开启Remote Server

https://static.1991421.cn/2022/2022-07-23-234044.jpeg

  1. iPhone/iPad Remote App下添加设备

    如果Wi-Fi网络下寻找不到该Mac可以直接输入IP/端口添加,根据提示输入短语即可添加成功,添加成功后即可在首页面板上看到对应Mac设备

https://static.1991421.cn/2022/2022-07-23-234317.jpeg

  1. 定制化remote操作面板

    在Mac Alfred Remote下按需定制面板,比如添加系统命令/workflow等。添加完成后,iPhone会自动同步更新

  2. remote系统设置

    为了更好的使用remote app,推荐设置中心开启以下设置项

    https://static.1991421.cn/2022/2022-07-23-234633.jpeg

使用场景

这里列举下当前我的一些贫瘠的使用场景

  1. 在利用Mac看电影时,可以通过remote来操作音量或者网页滚动操作
  2. 打开常用app/网页
https://static.1991421.cn/2022/2022-07-23-233342.jpeg

写在最后

  1. 一开始是冲着Alfred的喜爱购买,在吃灰多年之后,现在决定用起来,发现还是有场景需要的,毕竟可以远程操作Mac。
  2. 希望作者可以继续维护下去吧,期待能出些新的玩法/特性

最近用户反馈ssh密钥登陆Ubuntu系统时报认证错误,为此调查了下。

https://static.1991421.cn/2022/2022-07-18-215907.jpeg

排查

  1. 公私钥密码使用的RSA加密算法
  2. 尝试命令行直接SSH登陆,终端App为Mac自带Terminal

ssh -v -i ~/test.pem ubuntu@1.221.54.8

登陆发现可以成功,而webshell报错

注意

  1. SSH如果报错Permissions 0644 for ‘test.pem’ are too open.即确保私钥文件权限合适
1
chmod 400 test.pem

debug1: Local version string SSH-2.0-OpenSSH_8.6
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.9p1 Ubuntu-3

  1. ssh登陆成功后,想退出输入exit

分析

  1. 如上本地终端Terminal或iTerm2均可登陆成功,webshell不可以,webshell中用到了node模块ssh2。查询同使用该模块的shell产品,比如tabby,测试发现也是登陆失败,因此可以确定跟ssh2模块实现有关。
  2. ubuntu22.04是2022年4月发布的新系统,使用老版系统是发现没有该问题,因此也跟系统升级有关,查询发现新系统默认关闭SSH--RSA验证支持

综上可以确定新系统关闭RSA验证引发了该问题,而本地终端可以应该是其做了兼容支持,但node下ssh2模块明显没有兼容性支持。

解决方案

方案1-服务器配置修改

sudo vi /etc/ssh/sshd_config

增加如下配置PubkeyAcceptedKeyTypes +ssh-rsa

重启电脑生效

方案2-公私钥算法调整

重新创建公私钥,生成算法选择其它的,比如ed25519

方案3-客户端SSH2兼容性提升

大佬已有PR,支持,在没有合并发布新SSH2包之前可以临时调整版到如下版本解决。

1
"ssh2": "git@github.com:Eugeny/ssh2.git#22735cecf1d9c118b2b8af1c2f80fe5b04996fe1",

相关文档

最近开发中与Linux系统打交道较多,对于文件权限理解缺失,整理后这里总结下

文件权限说明

当终端执行ll命令等可以看到每个文件权限说明

比如drwx------ 7 lighthouse lighthouse 4096 Jul 12 12:00 lighthouse

开头的字母即权限说明,具体如下,大白话来理解即针对一个文件,该属性值明确了我,我们,他们的权限。

https://static.1991421.cn/2022/2022-07-16-160034.jpeg

权限判断

有了该文件的明确权限属性值,放在业务逻辑里,假如我们如何想判断一个文件针对用户是否有权限该如何做呢?

  1. 获取用户所属UID,GID,比如这里我执行ID命令id,拿到当前登陆用户lighthouse的用户信息

    1
    uid=1000(lighthouse) gid=1000(lighthouse) groups=1000(lighthouse)
  1. 获取文件所属uid,gid及文件权限信息,比如lighthouse文件夹

    1
    2
    3
    4
    5
    6
    7
    # 显示uid,gid
    ll -n
    drwx------ 7 1000 1000 4096 Jul 16 15:21 lighthouse

    # 显示owner,group名称
    ll
    drwx------ 7 lighthouse lighthouse 4096 Jul 12 12:00 lighthouse
  2. 权限判断

    • 如果用户uid===0,即为超级用户,直接拥有完整权限
    • 如果用户uid===文件uid即属于owner,则根据owner具体的rwx确定是否有对应权限
    • 如果用户不是owner而是属于同group,则根据group具体的rwx确定是否有对应权限
    • 如果用户不属于同group,则根据other具体的rwx确定是否有对应权限

说明

  1. root用户是特殊的存在,且ID固定不变
  2. uid===0的超级用户可能不唯一

举个🌰

比如root用户即不是lighthouse文件夹的owner也不是同组,且文件夹本身对于others也没有任何权限开放,但实际上root完全可以进行读写执行,因此也就印证了上述权限判断logic。

写在最后

玩好Linux,加油。

相关资料