手机浏览 RSS 2.0 订阅 膘叔的简单人生 , 腾讯云RDS购买 | 超便宜的Vultr , 注册 | 登陆
浏览模式: 标准 | 列表全部文章

git fetch --unshadow出现RPC failed

 远程操作家里的mac mini进行更新的时候,突然报错:

XML/HTML代码
  1. mini:Homebrew mini$ brew update  
  2. Warning: No available formula with the name "ca-certificates".  
  3. ==> Searching for similarly named formulae...  
  4. Error: No similarly named formulae found.  
  5. ==> Searching for a previously deleted formula (in the last month)...  
  6. Warning: homebrew/core is shallow clone. To get its complete history, run:  
  7.   git -C "$(brew --repo homebrew/core)" fetch --unshallow  
  8.   
  9. Error: No previously deleted formula found.  
  10. ==> Searching taps on GitHub...  
  11. Error: No formulae found in taps.  
  12. Error:  
  13.   homebrew-core is a shallow clone.  
  14. To `brew update`, first run:  
  15.   git -C /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core fetch --unshallow  
  16. This command may take a few minutes to run due to the large size of the repository.  
  17. This restriction has been made on GitHub's request because updating shallow  
  18. clones is an extremely expensive operation due to the tree layout and traffic of  
  19. Homebrew/homebrew-core and Homebrew/homebrew-cask. We don't do this for you  
  20. automatically to avoid repeatedly performing an expensive unshallow operation in  
  21. CI systems (which should instead be fixed to not use shallow clones). Sorry for  
  22. the inconvenience!  
于是执行 git -C /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core fetch --unshallow  ,然而执行下来还是:
XML/HTML代码
  1. error: RPC failed; HTTP 504 curl 22 The requested URL returned error: 504 Gateway Time-out  
  2. fatal: the remote end hung up unexpectedly  
 
然后我就用打开git trace进行查看:
XML/HTML代码
  1. GIT_TRACE=2 git -C /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core fetch --unshallow  
  2. 10:29:28.798061 exec-cmd.c:139          trace: resolved executable path from Darwin stack: /Applications/Xcode.app/Contents/Developer/usr/bin/git  
  3. 10:29:28.798668 exec-cmd.c:236          trace: resolved executable dir: /Applications/Xcode.app/Contents/Developer/usr/bin  
  4. 10:29:28.799328 git.c:418               trace: built-in: git fetch --unshallow  
  5. 10:29:28.801482 run-command.c:643       trace: run_command: GIT_DIR=.git git-remote-https origin https://mirrors.ustc.edu.cn/homebrew-core.git  
  6. 10:29:28.812513 exec-cmd.c:139          trace: resolved executable path from Darwin stack: /Applications/Xcode.app/Contents/Developer/usr/libexec/git-core/git-remote-https  
  7. 10:29:28.813122 exec-cmd.c:236          trace: resolved executable dir: /Applications/Xcode.app/Contents/Developer/usr/libexec/git-core  
  8. 10:29:28.929816 run-command.c:643       trace: run_command: git fetch-pack --stateless-rpc --stdin --lock-pack --include-tag --thin --depth=2147483647 https://mirrors.ustc.edu.cn/homebrew-core.git/  
  9. 10:29:28.935164 exec-cmd.c:139          trace: resolved executable path from Darwin stack: /Applications/Xcode.app/Contents/Developer/usr/libexec/git-core/git  
  10. 10:29:28.935863 exec-cmd.c:236          trace: resolved executable dir: /Applications/Xcode.app/Contents/Developer/usr/libexec/git-core  
  11. 10:29:28.936585 git.c:418               trace: built-in: git fetch-pack --stateless-rpc --stdin --lock-pack --include-tag --thin --depth=2147483647 https://mirrors.ustc.edu.cn/homebrew-core.git/  
  12. error: RPC failed; HTTP 504 curl 22 The requested URL returned error: 504 Gateway Time-out  
  13. fatal: the remote end hung up unexpectedly  
这个。。--depth=2147483647,居然这么深?
查到了网上的方案,参考在这里:记录: homebrew-core is a shallow clone - 腾讯云开发者社区-腾讯云 (tencent.com),我按上面的操作,删除了homebrew-core,homebrew-cask,再进行upgrade,果然 正常了。
 
---
在非正常之前,做了不少操作,比如用官方的uninstall脚本清除了系统,然而也没有什么用。所幸,现在正常了。
 
 

清除了模板中的一个防劫持的代码

在我的页面中第一行,其实以前一直有一行:<!--<!DOCTYPE html><head></head><body></body></html>-->

看起来好象没什么用,但其实他在http时代防止了不少运营商的页面劫持。那时候在没有https的时代,很多运营商会在网页的html里嵌入一个iframe,用来显示他们的广告或者其他内容。大部分都是往<head>里插入一个js或者在<body>里扔一个iframe,而我上面的代码,其实就在页面上有了两个head和body,但因为是注释的,所以即使这些运营商劫持了,他注入的内容往往都被注释掉了。
 
逃过一劫,但到了https的时代后,其实就比较难了。所以刚才在看到模板的时候,还是忍不住删除了。
看看以前的记录:

时代变化了,很多事情就这么过去了

悄悄的利用cloudflare做了个CDN前置

节后了,悄悄的用cloudflare做了个cdn前置,感觉速度确实快了不少。

不过,原来的服务器是放在阿里的轻量服务器香港。阿里在轻量上走的很早,但性能是越来越差,丢包越来越严重。真不知道是怎么想的。
现在再看阿里,推出了轻量负载均衡和数据库,鉴于阿里香港的表现情况,我是彻底不敢碰。由于我的服务器,有一台是明年到期,因为上面还挂着备案,所以暂时还不想退掉。1C1G,一年续费459,这个459是0带宽的。我最终还是选择了0带宽,然后弹性续费,毕竟其实只是为了绑个备案,没必要。
 
估计后续可能还是会先aws的lightsail,IP免费换(东南亚最便宜才3.5刀,当然,正常按5刀算)。现在想想真是走了很多弯路,早期10刀/20刀一个月的linode,后面换DO,各种小的国外轻量级KVM用着,慢慢的国内越来越便宜,逐步超越了那些国外的服务器。
 
Aws的费用确实太高,但lightsail,也真的还行。
不过,现在cloudflare的一些小功能倒是真的不错,也引入了R2,对标AWS的S3,免费流量和存储都是10G,这是冲着七牛来的啊。。。不知道后续发展会怎么样。反而国内的其他云存储吧,都开始按量计费了。又拍云呢,又不支持S3的协议,搞的反而是复杂了(还是简单的或者说还能支持FTP协议,是优点也是缺点。)
 
废话很多,只是感慨 一下

vite项目中使用process.env

 在Vite创建的项目中,如果直接使用process.env变量会报错,说是process未定义。查了下资料,原来这是vite3移除了这个变量:https://github.com/vitejs/vite/issues/1973

 
在项目的vite.config.ts的export default defineConfig中,增加节点:define{'process.env':{}}
如果要和你的env变量一致可以先loadEnv:
const root = process.cwd();
const env = loadEnv(mode,root);

 然后define节点就改成:define{'process.env':env}
 
此时,到项目里运行console.log(process.env),可以看到所有的变量。同时你会发现,只有VITE_开头的变量才能显示,其他都被隐藏了
 
在vite.config.ts中,建议是使用loadEnv来处理变量。否则如果你直接使用process.env。你会发现项目中所有的变量都显示了,一些系统变量也显示了,太危险。
 

mac下使用podman的代理大坑

关于这podman啊,一天天的,都在说要替换docker,然后也是大家各种说怎么弄怎么弄,教你安装podman之后,alias docker="podman" ,然后pip3 install podman-compose,再alias一条 alias docker-compose="podman-compose",说的这样好象就差不多了

 
确实,正常情况下,或者在linux\wsl的情况下,应该是差不多的,虽然部分命令不一样,但看一看参数,基本上也就过了。。。
mac下确实有一个大坑。因为mac其实是不支持container这玩意的。所以不管是docker也好,谁也好,都得装虚拟机。。。
早期podman的教程大多是让你安装一个ubuntu出的multipass,然后再各种连接,用podman连接远程(就是multipass出来的ubuntu虚拟机中安装一个podman)。。。手续也烦,教程也复杂。所以官方升级后出了一个简化版本:podman machine init/podman machine start。然后就可以各种操作了,确实方便很多。
 
然而问题也正是发生在这里。
> 且看我一步步操作
* brew update && brew install podman 
    * 正常更新,但由于有部分文件在raw.githubusercontent.com上,遇到这个,代表你只能用代理 了。于是ctrl+c
* export http_proxy=127.0.0.1:1087;export https_proxy=127.0.0.1:1087;export all_proxy=127.0.0.1:1080
* 再次执行:brew update&& brew install podman
    *顺利执行完
* podman machine init && podman machine start
    * 没问题,但这里要吐槽一下,安装的是fedora。。。好吧,我忍了。我纠结的是,为什么不能选择宿主操作系统?
* podman pull mysql
    * 问题就出来这里,拉包的时候,报错
```
podman create --name=pl-and-si-mysql-db --label io.podman.compose.config-hash=123 --label io.podman.compose.project=pipeline_combined_db --label io.podman.compose.version=0.0.1 --label com.docker.compose.project=pipeline_combined_db --label com.docker.compose.project.working_dir=/Users/gouki/Desktop/SC-REDBACK-main/database/pipeline_combined_db --label com.docker.compose.project.config_files=docker-compose.yaml --label com.docker.compose.container-number=1 --label com.docker.compose.service=pl-and-si-db -e MYSQL_DATABASE=database -e MYSQL_ROOT_PASSWORD=password -v pipeline_combined_db_pl_and_si_database_folder:/var/lib/mysql -v /Users/gouki/Desktop/SC-REDBACK-main/database/pipeline_combined_db/allInOne.sql:/docker-entrypoint-initdb.d/1.sql --net pipeline_combined_db_default --network-alias pl-and-si-db -p 3306:3306 --restart always --cpus 0.4 -m 350m mysql:latest
Resolving "mysql" using unqualified-search registries (/etc/containers/registries.conf.d/999-podman-machine.conf)
Trying to pull docker.io/library/mysql:latest...
Error: initializing source docker://mysql:latest: pinging container registry registry-1.docker.io: Get "https://registry-1.docker.io/v2/": proxyconnect tcp: dial tcp 127.0.0.1:1087: connect: connection refused
```
 
咦,他走了代理 ,但被拒绝?不可能啊,我前面下载软件的时候不是还好好的么,难道是代理错误?于是我新开一个shell窗口,再次执行,仍然是同样的错误,这回就发现问题了,因为新的shell窗口我env|grep -i proxy的时候,返回为空,当前进程没有任何一个proxy参数
 
找了一堆podman的配置,打印了podman info也没有找到有代理 设置的地方,最后只能问google。搜索了半天,只搜到一个有效贴,还是在官方的[issue](failed to pull image when use system proxy · Issue #14087 · containers/podman (github.com))里
 
有人这样回复:
```

The proxy is set correctly: proxyconnect tcp: dial tcp 127.0.0.1:7890: connect: connection refused

The problem is that your proxy is listening on 127.0.0.1. Obviously 127.0.0.1 inside the VM is a different address and therefore it cannot connect to the proxy on you actual host.

If you set http_proxy=socks5://host.containers.internal:7890 before you run podman machine init it should work.
Maybe podman should just s/127.0.0.1/host.containers.internal and s/localhost/host.containers.internal automatically when it copies the proxy value from the host.

```
 
感情是你只要machine init的之前用了代理 ,init完后。针对vm的参数就变了。于是下面就有人说,你可以这样:
 
```

I just test it and I think you are right, but I don't know why http_proxy=socks5://host.containers.internal:7890 podman machine init this command still hit the same error but it works as expected when I add 127.0.0.1 host.containers.internal to my host file

however it works now

add item blow to host file

127.0.0.1 host.containers.internal

and change proxy to

http_proxy=socks5://host.containers.internal:7890

then everything works fine

much thanks @Luap99 for your help and I close this issues for the problem is solved, but I still stay concerned if some day podman can do this itself and no need to change proxy setting

```

 

呵呵,这么麻烦?我还是新建一个shell窗口:podman machine stop && podman machine init && podman machine start吧。

然后,podman pull mysql,一切正常~

 

至此搞定。

 

> 假装内容支持markdown,因为新模板在寻找中,现在的html所见所得,估计会全部改成markdown,先尝试一下。