易栈网-膘叔

浏览模式: 标准 | 列表 | 图文
aliyun composer 镜像可能有问题

aliyun composer 镜像可能有问题

好几次遇到阿里云的镜像更新有问题了,明明某个库有了最新版,但阿里云就是报版本不存在。今天又出现了这样的情况,安装laravel-zero的时候,require-dev中有个laravel/pint ^1.2,直接就报了

Problem 1
- Root composer.json requires laravel/pint ^1.2, found laravel/pint[dev-main, v0.1.0, ..., v0.2.4, v1.0.0, ..., v1.1.3] but it does not match the constraint.
问题是这个laravel/pint 的github上,1.2的release是 9月13日啊。(laravel/pint: Laravel Pint is an opinionated PHP code style fixer for minimalists. (github.com))。
由于之前也遇到过这个问题,当时是unset掉 aliyun镜像,换成了官方镜像,但确实是慢,所以我就看了一眼其他镜像,比如以前常用的https://packagist.phpcomposer.com,在国内没有其他镜像的时候,它做了很大的贡献,然而也太不稳定了。直接报:

Problem 1 - Root composer.json requires laravel-zero/framework, it could not be found in any version, there may be a typo in the package name. Problem 2 - Root composer.json requires nunomaduro/termwind, it could not be found in any version, there may be a typo in the package name. Problem 3 - Root composer.json requires laravel/pint, it could not be found in any version, there may be a typo in the package name. Problem 4 - Root composer.json requires mockery/mockery, it could not be found in any version, there may be a typo in the package name. Problem 5 - Root composer.json requires pestphp/pest, it could not be found in any version, there may be a typo in the package name. Potential causes: - A typo in the package name - The package is not available in a stable-enough version according to your minimum-stability setting see <https://getcomposer.org/doc/04-schema.md#minimum-stability> for more details. - It's a private package and you forgot to add a custom repository to find it Read <https://getcomposer.org/doc/articles/troubleshooting.md> for further common problems.

看来,已经多年没有更新过了,真可惜了。
最后在这里找到了:国内 PHP Composer 镜像列表 - 腾讯云开发者社区-腾讯云 (tencent.com),列表中的那些镜像,象最后的安畅网络的,网址都崩了。所幸,腾讯的还能用。
打开:腾讯软件源 (tencent.com),搜到composer,看一下帮助(真简单就两句话),一句教你配置,一句教你下载。
配好之后,composer u,完成。记录一下
1、阿里:composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
2、腾讯:composer config -g repos.packagist composer https://mirrors.tencent.com/composer/
3、清除:composer config -g --unset repos.packagist
带 -g 的是全局的,不带 -g,就是当前项目了。

又做了一次服务网站的迁移

又做了一次服务网站的迁移

在很久很久以前,我其实一直是使用阿里云的,直到后面腾讯也出了云。当然使用量明显没有阿里大,而且我还一直是推荐阿里的。

由于国内的一些原因,有些网站没法备案(比如个人网站,还不能介绍自己做的项目,只能用公司网站。。),所以,部分网站采用了香港的服务器。
在早些年吧,用aws的lightsail,便宜,但没有香港区,只有:日本、韩国、新加坡,这些地区吧,白天访问都挺正常,一到晚上就开始抽风,于是几乎全部撤出,采用阿里云香港。
前两年都挺OK。好象从21年起,阿里云香港也开始逐步抽风了,最高的时候丢包率达到了25%左右,白天也是一切正常。
因此只能想办法再尝试尝试换了。这次就换到腾讯去了,看看效果如何。
--
话说从03年到现在,也算是用了不少服务器了。
04~05,自己买AMD的芯片组装的windows服务器,托管在上海漕河泾,后因为那边经常断电烧坏了
08年开始,买了朋友的一台dell的2U,托管在edong,也是因为他们迁机房的问题,导致我整个断网2个月,alexa排名从1万掉到10万开外,就再也没有恢复过
11年开始使用linode,然后就是各种其他的大大小小的、知名的不知名的服务器都在尝试,感觉就是在不停踩坑
用过GCP、AWS,还有盛大云、DO,OVH的等。后面因为开始做外包,慢慢全部不再使用,直接用国内的阿里云,这两年在慢慢切回腾讯云。
有几个小原因,比如备案,你在A站备案,到腾讯还是不能使用2级域名。必须要在他那边备案,所以才不得不使用香港主机,先用起来,后面备案再切。所幸现在的网站都是git来git去的。基本上部署一个网站也就半小时就行了。
没用docker,PHP用docker感觉没啥大意义。之前用过,因为要跑不同的PHP版本,从5.6~8都有,那时候不得不用docker。现在基本上都以7.4为主,即使上8也不会有大问题,所以不再使用Docker了。
废话说的太多了,睡觉~
uniapp backgroundImage 无法显示

uniapp backgroundImage 无法显示

突然发现uniapp好象无法分类。

用uniapp的时候突然发现使用背景图的时候打包无法打进去。本来这也没多大事,毕竟所有的图片几乎都是从网上拉过来的。但只是一个背景色也要从网上下载就有点麻烦了。所以就看了一下
1、如果不是变量的,得用相对路径,比如 /static/background.png,要写成 ../../static,注意当前文件和static的相对路径
2、如果是变量的,得一一require进来。然后用变量与require的对量对应
3、或者你还是用image标签,但是这个image标签外用view做好对应,如果上面有堆叠其他内容,会相对比较麻烦一点
4、还是用网上的地址吧,尽量使用云存储,不然如果是小水管网站,这么一拉取,其他内容可能变被卡住了。
基本上就这么些方法。
Tunnel error on MacOS when installed as service

Tunnel error on MacOS when installed as service

其实我一直在想,这个功能什么时候会被关掉。

开始:
用cloudflare tunnel的时候,从没想过会在macos上出问题,如果你直接cloudflared service install,不会运行,即使你sudo了也不会,因为这个运行的只是cloudflared,并不带任何参数。
需要在相应的plist下面加上<string>tunnel</string><string>run</string>才OK。
加之前需要先unload,然后再load。否则无效。
其他都与官方一致。
---
如果用sudo了。需要将~/.cloudflared/下的内容copy到/etc/cloudflared下面。如果不放心或者担心没权限,可以修改uuid.json,将路径改为/etc/cloudflared/。其他照旧
记得配合一下valet,因为valet tld之后,子域名的映射会比较方便。
而且valet也支持multi php version。
---EOF
git fetch --unshadow出现RPC failed

git fetch --unshadow出现RPC failed

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

mini:Homebrew mini$ brew update
Warning: No available formula with the name "ca-certificates".
==> Searching for similarly named formulae...
Error: No similarly named formulae found.
==> Searching for a previously deleted formula (in the last month)...
Warning: homebrew/core is shallow clone. To get its complete history, run:
git -C "$(brew --repo homebrew/core)" fetch --unshallow

Error: No previously deleted formula found.
==> Searching taps on GitHub...
Error: No formulae found in taps.
Error:
homebrew-core is a shallow clone.
To `brew update`, first run:
git -C /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core fetch --unshallow
This command may take a few minutes to run due to the large size of the repository.
This restriction has been made on GitHub's request because updating shallow
clones is an extremely expensive operation due to the tree layout and traffic of
Homebrew/homebrew-core and Homebrew/homebrew-cask. We don't do this for you
automatically to avoid repeatedly performing an expensive unshallow operation in
CI systems (which should instead be fixed to not use shallow clones). Sorry for
the inconvenience!
于是执行 git -C /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core fetch --unshallow ,然而执行下来还是:
error: RPC failed; HTTP 504 curl 22 The requested URL returned error: 504 Gateway Time-out
fatal: the remote end hung up unexpectedly
然后我就用打开git trace进行查看:
GIT_TRACE=2 git -C /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core fetch --unshallow
10:29:28.798061 exec-cmd.c:139 trace: resolved executable path from Darwin stack: /Applications/Xcode.app/Contents/Developer/usr/bin/git
10:29:28.798668 exec-cmd.c:236 trace: resolved executable dir: /Applications/Xcode.app/Contents/Developer/usr/bin
10:29:28.799328 git.c:418 trace: built-in: git fetch --unshallow
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
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
10:29:28.813122 exec-cmd.c:236 trace: resolved executable dir: /Applications/Xcode.app/Contents/Developer/usr/libexec/git-core
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/
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:29:28.935863 exec-cmd.c:236 trace: resolved executable dir: /Applications/Xcode.app/Contents/Developer/usr/libexec/git-core
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/
error: RPC failed; HTTP 504 curl 22 The requested URL returned error: 504 Gateway Time-out
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前置

节后了,悄悄的用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

在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的代理大坑

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,先尝试一下。

千辛万苦搭建了一台gitea server

千辛万苦搭建了一台gitea server

一直使用github,也有因为各种原因使用过不少的git server,比如:codeup/gitee/coding/甚至腾讯工蜂,国外的么,bitbucket/gitlab其实也都有使用,这里面带来的最大的问题就是网络问题,当然国内的没这个毛病,但比如gitee,不能超过3个协作者(个人账户),coding的话,我个人是很喜欢的,甚至想成为他们的商业用户,但商业用户需要至少5个使用者。(国内好象其他平台也差不多,要想成为商业用户,几乎最少人数都是5人,一年500多我愿意付出,但2500多确实没有太大必要)

github/gitlab 当然没什么问题,但偶尔的不能访问也确实有点麻烦,这些都不是重要的。github也尝试过通过Action来进行自动部署,但确实不舒服,连接国内进行部署的时候,一个40多M的jar包。有一次传输上就花了将近10分钟,这种在国外向国内进行传输速度,有时候还是挺抽风的。
于是搭建git server的相法就开始了。之前其实也搭过,从16年开始,基本上就是用gogs,当然也不是没遇过问题,比如超过50M时就无法上传之类的。这时候就要改nginx最大允许的post max size了。这次是看到说gitea推出了【包管理(Package Registry)】,然后才决定使用的。
然而在使用的时候,就开始遇到各种问题了。比如不能运行在root下,腾讯的轻量默认是root用户嗯,cvm/阿里云的ecs,也是root,但阿里云的轻量,默认居然是admin。有点妖
然后创建git用户,测试su git -c '/usr/local/bin/gitea web'进行测试。到这里都没啥问题,然后我就开始遇到问题
1、用nginx做反向代理 ,毕竟我也不可能一直用ip+port进行访问,然而css/js全部无法访问,检查了很久,才发现原来是默认的配置文件里对css/js等静态文件做了过期时间设置,但因为最早3000端口被 zerotier的UI占用了。这时候他就一直不过期了。所以一直就无法访问(在缓存里?)这个有点麻烦,现在很多路径都是/assets/css/css.css,这种自动生成的格式,所以大部分自动打包的可能路径都是这种,这时候一旦被缓存了,短时间内就一直无法变改。这很纠结
2、ssh 登录,这个才是大坑。其实也是怪我自己,如果我允许port登录,估计早就解决了。比如我可以让root用户通过自定义端口登录,然后git用户就可以通过22端口登录了。(测试过可行,但不太想改默认登录端口,想复用端口,结果就启动不了了,好象非root用户进行的项目,无法使用1024以下端口)
3、最后只能使用docker来进行部署,然后因为我偷懒没使用docker,用了podman。。。默认安装的podman是3.0.4,使用podman-compose的时候有问题。于是又升级到4.2,然后才能正常使用podman-compose。对着官方文档配置 gitea脚本以及 默认的转发(再折腾了1个小时才搞完)
先做个笔记,后面看什么时候有空补上详细的,以后重装也能更方便一点