SSL Error

当 jupyter 配置了 SSL 时, Nginx 反向代理时也需要用 https 协议

例如, 反向代理到本地的 10000 端口

错误示范

1

proxy_pass http://127.0.0.1:10000;

正确示范

1

proxy_pass https://127.0.0.1:10000;

Websocket 连接问题

在基于 Docker 部署 jupyter 工作环境时, 可能会发生可以打开网页, 可以创建文件, 但是无法与后端 python 连接的情况.

查看 jupyter 日志显示

1
2
3
4
5
6

jupyter    | [W 2021-09-21 16:09:24.778 ServerApp] 400 GET /terminals/websocket/1 (172.27.0.1) 1.21ms referer=None
jupyter    | [W 2021-09-21 16:09:26.418 ServerApp] 400 GET /terminals/websocket/1 (172.27.0.1) 1.13ms referer=None
jupyter    | [W 2021-09-21 16:09:28.696 ServerApp] 400 GET /terminals/websocket/1 (172.27.0.1) 1.28ms referer=None
jupyter    | [W 2021-09-21 16:09:30.660 ServerApp] 400 GET /terminals/websocket/1 (172.27.0.1) 1.24ms referer=None
jupyter    | [W 2021-09-21 16:09:37.605 ServerApp] 400 GET /terminals/websocket/1 (172.27.0.1) 1.15ms referer=None
jupyter    | [W 2021-09-21 16:09:41.758 ServerApp] 400 GET /terminals/websocket/1 (172.27.0.1) 1.11ms referer=None

当我尝试用 jupyter 提供的 terminal 时, 发现以上日志.

这说明这个请求没有成功, 400 状态码参考 MDN

1

HTTP 400 Bad Request 响应状态码表示由于语法无效，服务器无法理解该请求。 客户端不应该在未经修改的情况下重复此请求。

所以应该是 nginx 在与 jupyter 通信时发生了问题.

Google …

找到以下解决方案, 一个可用的 Nginx 反向代理配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

location / {
    proxy_pass http://jupyter;

    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

location ~* /(api/kernels/[^/]+/(channels|iopub|shell|stdin)|terminals/websocket)/? {
    proxy_pass http://jupyter;

    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

    # WebSocket support
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;

}

注意添加这三项

1
2
3

proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;

参考链接

https://github.com/jupyter/notebook/issues/625

https://jupyter-notebook.readthedocs.io/en/latest/config.html#options

https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/400

https://gist.github.com/cboettig/8643341bd3c93b62b5c2

问题描述

在用 crontab 定时备份 gitlab 时, 发现任务总是不成功. 😱😱😱

命令如下

1

0 0 * * * /root/docker/gitlab/backup-gitlab.sh >> /root/docker/gitlab/backup-gitlab.log 2>&1

测试后发现日志总是没有任何输出, 说明这个命令没有被执行. 🤔🤔🤔

随便写了条命令测试

1

* * * * * echo "`date`" > /root/crontest.log

发现有输出…. 😲😲😲

那么说明 crontab 确实工作了…. 😵😵😵

沉思…. 🤔🤔🤔

解决方案

虽然我不太清楚是什么原因, 但是当我把以下配置加入 crontab 后他开始工作了. 😄😄😄

1
2
3
4

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/

也许是因为显式指定了 shell, 以及一些其他的一些参数, 导致可以正常工作, 因为我之前一直怀疑是权限的问题. 🤣🤣🤣

参考连接

https://my.oschina.net/leejun2005/blog/1788342

问题以及解决方案

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