起因

起了把家里路由器更新到新版本OpenWRT的念头很久了,周末终于克服自己的懒病,下载了OpenWRT 19.07.4的安装包,更新Linksys WRT1900ACS路由器的系统。

修改了IP地址,把Wifi打开后,驾轻就熟地修改了相关的配置,增加了第三方源,准备开始安装你懂的SS和ChinaDNS等组件。没想到往常屡试不爽的opkg install命令返回了安装失败提示:

Incompatible with the architectures configured

仔细比对了所有的配置,确认没有错误,但是安装新增的第三方包时总是报错。

解决方法

试了N多种方法,还是不行,正准备放弃装回原来ROM时,突然发现运行opkg print-architecture返回的CPU架构型号是
arch all 1
arch noarch 1
arch arm_cortex-a9_vfpv3-d16 10

比原来系统打印出来的架构型号多了一个d16,而第三方源的库里貌似没有arm_cortex-a9_vfpv3-d16这样一个型号的源,尝试修改/etc/opkg.conf文件,把原来CPU型号列表增加不带d16行。
arch all 1
arch noarch 1
arch arm_cortex-a9_vfpv3 8
arch arm_cortex-a9_vfpv3-d16 10

再运行opkg install,包装成功。

[heading]起因[/heading]

系统升级后,因为要安装python开发环境方便,想安装brew,但尝试运行brew命令命令

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"

系统却直接报错。

Error: Failure while executing; `git clone https://github.com/Homebrew/homebrew-core /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core` exited with 128.

Error: Failure while executing; `/usr/local/bin/brew tap homebrew/core` exited with 1.

Failed during: /usr/local/bin/brew update –force

以为是网络问题,架上梯子后重新运行,问题依旧。

[heading]解决方法[/heading]

手工用git把brew拉到本地目录,重新把运行安装命令,成功解决。

git clone https://github.com/Homebrew/homebrew-core /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core --depth=1 

起因

好久没登上服务器,一上班手贱上去运行了一把ghost update,升级到ghost 3.18.1,结果在重启ghost服务时就卡住了,转了老半天没有结果。手工启动ghost报错。放狗搜了一番,说是Nodejs版本太低的原因。上ghost官网查了兼容列表,确实是推荐使用nodejs v12。于是升级nodejs,再升级了ghost-cli,但是ghost服务还是没法成功启动。

解决方法

开始想偷懒,想着大不了强制升级一次。于是运行强制升级命令。

ghost update --force

结果连升级都报错。

运行ghost doctor,诊断结果报unknown error。

没有办法,尝试直接ghost run,发现网站可以运行,但是会报一个错。

WARN Can't connect to the bootstrap socket (localhost 8000) ECONNREFUSED

打开ghost配置文件config.production.json,发现有一节bootstrap-socket的配置内容。备份配置文件,把该节内容整个删除。

重启ghost,服务恢复正常。

[heading]起因[/heading]

新冠返沪自我隔离期间,因为无聊把各家云计算厂商的产品和技术体系撸了一遍。对于O记的OCI,通读了一遍Apress的《Practical Oracle Cloud Infrastructure》。恰好本周O记渠道部组织了一场为期4天的OCI认证培训,想着趁此机会去实操一把,刚好加深对OCI整个体系架构的理解。 通过了解,知道对OCI资源的操作,可以通过以下四种方式:

  • Web Console
  • API
  • CLI
  • Terraform

Console最直观,但是相信实际操作过的人都会对云厂商那种极不用户友好的操作界面深恶痛绝。 API拿DonetCore写了几个试验应用通过REST API很简单就调通了。 Terraform方式还没有去试。结合培训,重点测试CLI的方式,毕竟平时做实验也是CLI最方便。于是开了一台Windows 10虚机,按照官方文档安装CLI,没想到基本上一场恶梦的开始。此文为折腾的记录。

[heading]Windows 10下安装CLI第一次尝试[/heading]

官方文档的描述,以管理员身份启动Windows的PowerShell终端,运行以下命令:

Set-ExecutionPolicy RemoteSigned
powershell -NoProfile -ExecutionPolicy Bypass -Command "iex ((New-Object System.Net.WebClient).DownloadString('https://raw.githubusercontent.com/oracle/oci-cli/master/scripts/install/install.ps1'))"

运行报错,提示“[highlight dark=”no”]使用“1”个参数调用“DownloadString”时发生异常:“无法连接到远程服务器[/highlight]””错误。

无法连接到远程服务器 看来是因为网络连接问题,在大天朝也算正常。轻车熟路地架梯子,确认可以连接外网后重新运行命令,这次系统开始提示下载Python,坚持了10来分钟还是报错,提示超时。 修改网络配置,重试了几次都是同样错误。因为机器没有Python,所以直接到Python官网,下载安装了Python 3.7,准备绕过安装脚本自动安装Python的步骤。

[heading]Windows 10下安装OCI CLI之升级Pip[/heading]

安装好Python,再次运行OCI的CLI安装脚本。这次有点反应,安装程序开始下载Python的支持包,结果到了一半又是出错,看错误信息有提示说[highlight dark=”no”]”You are using pip version 19.2.3, how ever version 20.0.2 is available You should consider upgrading via the ‘python -m pip install –upgrade pip”[/highlight],没有仔细分析安装脚本,以为是pip版本的原因(其实应该可以运行CLI的)。   直接照着提示,在PowerShell运行”python -m pip install –upgrade pip”,回车后没有反应,大概是安装Python时没有设置环境变量所致。于是切换至Python安装目录的Scripts目录下,重新运行

pip install --upgrade pip

升级pip后再试。 [heading]Windows 10下安装OCI CLI之安装成功[/heading] 再次运行安装脚本,这次开头很顺利地安装Python支持包,以为肯定可以了,没想到过了一会还是报错。

CLI错误

iex ((New-Object System.Net.WebClient).DownloadString('https://raw.githubusercontent.com/oracle/oci-cli/master/scripts/ install/install.ps1')) : Executing C:\Python37\python.exe "C:\Users\QJJ\AppData\Local\Temp\tmp316C.tmp" returned a non- zero exit code. 所在位置 行:381 字符: 9 + Write-Error "Executing $PythonExecutable $ArgumentList return ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException

放狗搜了一番,github上的解决方式基本通过修改PowerShell的代理服务器地址或者直接修改脚本内容的方式,但最近的issue也是几个月前了,相信O记应该修复了吧。所以还是把重点放在自己的网络问题上。 把SS设置为全局模式,保证所有的网络流量都通过梯子。再次运行安装脚本,经过一段颇为漫长的等待,终于把CLI在Windows 10下安装成功。

CLI Install Python Pakcages

[heading]总结[/heading] 从这次安装的折腾过程来看,OCI的用户友好性还是有待提升,哪怕是问题,好歹也给个提示哪里出问题不是? 另外,要通过CLI或者API方式访问OCI,需要保证网络能够顺畅地访问外网,不然的话很容易出现各种奇奇怪怪的问题。看来O记各位在国内推广OCI的朋友,还是任重而道远呀:)