0%

问题以及解决方案

you should not run configure as root (set FORCE_UNSAFE_CONFIGURE=1 in environment to bypass this check)

错误提示:

1
you should not run configure as root (set FORCE_UNSAFE_CONFIGURE=1 in environment to bypass this check)

如果你以root用户运行编译, 会有这个提示. 有两个解决方案, 你可以换一个非root用户, 或者接忽略提示.

1
export FORCE_UNSAFE_CONFIGURE=1

参考链接

https://blog.csdn.net/tx422/article/details/78593860

项目基于 docker 搭建.

编辑 gitlab.rb 文件

该文件在容器里的路径为

1
/etc/gitlab/gitlab.rb

编辑一下内容

1
2
3
4
5
6
7
8
9
gitlab_rails['manage_backup_path'] = true
# gitlab备份目录
gitlab_rails['backup_path'] = "/var/opt/gitlab/backups"

# 生成的备份文件权限
gitlab_rails['backup_archive_permissions'] = 0644

# 备份保留天数,秒计算, 86400 * 7 = 604800 保留 7 天
gitlab_rails['backup_keep_time'] = 604800

更新 gitlab 配置

1
gitlab-ctl reconfigure

使用 crontab 添加定时任务

1
crontab -e

添加配置, 每天 0 点备份

1
0 0 * * * /opt/gitlab/bin/gitlab-rake gitlab:backup:create

查看备份文件, 备份目录在容器里的路径

1
/var/opt/gitlab/backups

查看

1
2
cd /var/opt/gitlab/backups
ls

参考链接

https://blog.csdn.net/rdp1305442102/article/details/105768441

实验路径

1
/opt/au1200_rm/build_tools/bin

直接用export命令

1
export PATH=$PATH:/opt/au1200_rm/build_tools/bin

以上命令将实验路径导入到环境变量, 下次登录失效

修改profile文件

1
nano /etc/profile

加入

1
export PATH=$PATH:/opt/au1200_rm/build_tools/bin

以上命令将实验路径导入到环境变量, 下次登录有效

修改.bashrc文件

1
nano /root/.bashrc

加入

1
export PATH=$PATH:/opt/au1200_rm/build_tools/bin

以上命令将实验路径导入到环境变量, 未测试下次登录是否有效

参考链接

https://www.cnblogs.com/leezx/p/5589941.html

正确的做法

1
2
3
4
5
6
7
8
9
10
11
#!/bin/sh

STRING=

if [ -z "$STRING" ]; then
echo "STRING is empty"
fi

if [ -n "$STRING" ]; then
echo "STRING is not empty"
fi

输出正确的结果:

1
2
root@james-desktop:~# ./zerostring.sh
STRING is empty

错误的做法

1
2
3
4
5
6
7
8
9
10
11
#!/bin/sh

STRING=

if [ -z $STRING ]; then
echo "STRING is empty"
fi

if [ -n $STRING ]; then
echo "STRING is not empty"
fi

输出错误结果:

1
2
3
root@james-desktop:~# ./zerostring.sh
STRING is empty
STRING is not empty

总结

记得在给变量加上双引号””

参考链接

https://www.cnblogs.com/cute/archive/2011/08/26/2154137.html

在 shell 脚本里使用 ssh 在远程主机执行脚本时无法关闭连接

例如

1
ssh user@ipaddress '~/my_script.sh'

脚本执行完毕连接不会关闭, 需要你手动 Ctrl + C 关闭连接.

解决方案

1
ssh user@ipaddress '~/my_script.sh && exit'

当你在远程主机执行的脚本由本地主机推送的话

例如

1
ssh user@remoteNode < test.sh

你可以在本地脚本里添加

1
kill -SIGHUP $PPID

kill 掉当前的 ssh

但是这样会导致, 你尝试捕获 SSH 是否成功执行时, 总是得到失败的结果.

参考链接

https://superuser.com/questions/207453/ssh-and-shell-through-ssh-how-to-exit?noredirect=1&lq=1

连接时加入StrictHostKeyChecking=no

例如

1
ssh -o StrictHostKeyChecking=no root@192.168.1.100

动态查看日志

1
tail -f  /var/log/gitlab/gitlab-rails/production.log

迁移或恢复备份后部分操作服务端响应500

进入容器, 运行

1
gitlab-rails dbconsole

依次清除 token, 注意! 这样会清除全部的 token, 不过解决问题简单粗暴

1
2
3
4
5
6
-- clear project tokens
UPDATE projects SET runners_token = null, runners_token_encrypted = null;
-- clear group tokens
UPDATE namespaces SET runners_token = null, runners_token_encrypted = null;
-- clear instance tokens
UPDATE application_settings SET runners_registration_token_encrypted = null;

造成这个问题的原因是因为没有备份这个文件

1
gitlab-secrets.json

以后操作的时候还是要多看看官方文档, 文档说的很清楚…

https://docs.gitlab.com/ee/raketasks/backup_restore.html

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
When the secrets file is lost
If you didn’t back up the secrets file, you must complete several steps to get GitLab working properly again.

The secrets file is responsible for storing the encryption key for the columns that contain required, sensitive information. If the key is lost, GitLab can’t decrypt those columns, preventing access to the following items:

CI/CD variables
Kubernetes / GCP integration
Custom Pages domains
Project error tracking
Runner authentication
Project mirroring
Web hooks
In cases like CI/CD variables and runner authentication, you can experience unexpected behaviors, such as:

Stuck jobs.
500 errors.

Whoops, GitLab is currently unavailable.

可以正常查看项目列表, 但是无法进入项目, 错误提示

1
Whoops, GitLab is currently unavailable.

项目基于docker容器部署, 首先查看日志, 发现一条错误, 权限拒绝.

1
{"error":"open /var/opt/gitlab/gitaly/gitaly.pid: permission denied","level":"fatal","msg":"find gitaly","time":"2021-05-05T18:05:26Z","wrapper":3514}

google 发现, 这个文件在 docker 容器里的权限应该是 git:git

但是我进入容器后发现该文件的权限为 root:root

1
2
3
4
5
6
-rw-r--r-- 1 root root   63 May  5 16:51 RUBY_VERSION
-rw-r--r-- 1 root root 23 May 5 17:56 VERSION
-rw-r----- 1 root git 819 May 5 17:56 config.toml
-rw------- 1 root root 3 Mar 8 18:57 gitaly.pid
srwxr-xr-x 1 root root 0 Mar 8 18:57 gitaly.socket
drwx------ 2 git root 4096 Mar 8 18:57 internal_sockets

修改权限

1
chown git:git gitaly.pid

Errno::EEXIST: File exists @ dir_s_mkdir - /var/opt/gitlab/backups/repositories

备份的时候出现这个问题, 十有八九是权限问题.

直接

1
chmod -R 777 bakcups

参考连接

https://forum.gitlab.com/t/local-gitlab-is-not-longer-working/29319/19
https://docs.gitlab.com/ee/raketasks/backup_restore.html

Koolshare-Clash 的 Github 地址

https://github.com/SukkaW/Koolshare-Clash

这个项目已经两年没更新了, 项目自带的 Clash 版本为 Clash v0.20.0 已经很旧了.

目前为止 Clash 的最新版本为 Clash v1.5.0

笔者尝试更新 Clash 版本, 但是遇到的一些问题, 这里记录一下解决方案.

更新 Clash 版本

笔者的路由器为LEDE_X86 for linux, 首先通过 SSH 登录后台.

切换到目录

1
cd /koolshare/bin

去 Github 下载对应的平台的最新的 Clash

1
https://github.com/Dreamacro/clash

删除旧的 Clash

1
rm clash

把新的 Clash 拷贝进去, 然后更改权限

1
chmod 755 clash

然后去 Koolshare 重启 Clash

可能出现的问题

访问代理后台看不见配置的代理

出现这种原因是因为 0.20.0 的配置文件和 1.5.0 配置文件有些字段更改了, 需要更改 Clash 的配置文件

访问该网址可以查看最新的配置文件规则

1
https://github.com/Dreamacro/clash/wiki/configuration

一些差异

1
2
3
4
5
6
7
8
0.20.0 -> Proxy
1.5.0 -> proxies

0.20.0 -> Proxy Group
1.5.0 -> proxy-groups

0.20.0 -> Rule
1.5.0 -> rules

配置文件从1.0.0版本开始更改.