Git 仓库迁移历险记

作者:wiLdGoose 发布时间:December 17, 2018 分类:技术 Technology

前阵子折腾了一个 Git 仓库迁移,觉得有必要自行马克一下。

需求背景:老的版本库在一台 Windows 主机上,用 Gitblit 搭建;我在某云用一台独立主机新搭建了一套 Gitlab,前端由另一台主机部署 Nginx 反向代理。
需求内容:将老版本库的所有仓库平滑迁移到新的版本库中。
任务拆解:部署并配置 Gitlab、创建项目仓库、镜像推送、将原先指向到 Gitblit 的域名解析修改到 Gitlab、导入账户,完成。

在一切都顺利进行的时候遇到一个大小为 2G 多的仓库,零碎文件较多,最大的单文件也就几百兆。由于我本地没有这个仓库,于是:

$ git clone https://path.to.git/repo.git

进度到 20% 多的时候,死活就断开了,反复尝试无效:

Cloning into 'repo'...
remote: Counting objects: 27709, done
remote: Finding sources: 100% (27709/27709)
remote: Getting sizes: 100% (16855/16855)
remote: Compressing objects:  23% (69/300)
error: RPC failed; curl 18 transfer closed with outstanding read data remaining
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

网上找到有人说需要更改一下 Git 客户端的上传限制大小:

$ git config http.postBuffer 524288000

或者直接修改 .gitconfig 文件,修改 [http] 段:

postBuffer = 524288000

好了,依然失败。万般无奈之下找同事 copy 了整个 Git 文件夹到我本地,修改 Git 用户配置文件,git pull,成功。接着修改配置文件到新的版本库地址,然后就是见证奇迹的时刻:

$ git push -u origin --all
Enumerating objects: 27705, done.
Counting objects: 100% (27705/27705), done.
Delta compression using up to 4 threads.
Compressing objects: 100% (12552/12552), done.
error: RPC failed; HTTP 413 curl 22 The requested URL returned error: 413 Request Entity Too Large
fatal: The remote end hung up unexpectedly
Writing objects: 100% (27705/27705), 1.97 GiB | 2.17 MiB/s, done.
Total 27705 (delta 12742), reused 27100 (delta 12209)
fatal: The remote end hung up unexpectedly
Everything up-to-date

与 clone 的时候一样,push 到一定程度就断开,反复尝试死活不行。想了半天不得其解,考虑到前端用 Nginx 做了反代,Google 之。有人说:

在服务器上面配置了 Nginx 之后,使用 Git 上传大文件的时候会出现“HTTP 413 curl 22 The requested URL returned error: 413 Request Entity Too Large”。

嗯,好像是找到问题了?于是修改 Nginx 的配置文件 nginx.conf,在 http 段加入:

client_max_body_size 1024m;

原文说 2m 够了,我贪心,直接加到 1024m。重启 Nginx,哈哈……特么的还是失败了。

眼睛盯着别人的仓库 URL 和我的 URL,总觉得哪里不对劲。原来 git@path.to.git/repo.git 走的是 SSH 协议,我的 https://path.to.git/repo.git 走的是 HTTP 协议。

改!一顿操作,改 sshd 端口号,配置 Gitlab 为 SSH 方式,到 Gitlab 后台对项目启用 SSH 方式,再次尝试……激动得眼泪都留下来了,成功。

结论:HTTP 协议不适合于大型项目的仓库,能走 SSH 就走 SSH 吧。

本博全站启用防核泄保护

作者:wiLdGoose 发布时间:May 12, 2011 分类:生活 Lifestyle

河蟹社 5 月 12 日讯:

本博在美帝一直都有独立的固定 IP,然而只承载了几个小站的 IP 最近变得十分不稳定。眼看 SSL 证书也快到期,干脆 Revoke 掉重新买一个。折腾一个晚上,浪费近百刀买了 N 个证书才算搞定。结果是一口气续费了 5 年的主机,买了 5 年的证书。在此感谢狗爸爸的马甲——Starfield,学到不少,没白交学费。

日本国的核泄事故教训必须得吸取啊,本博宣布:已从 2011 年 5 月 11 日开始全站启用防核泄保护,即日起请通过 https://www.xuchao.org 来访问本站,RSS 地址不变,所有未通过 https 访问的请求将被重定向到带 https 的地址。

感谢所有应该被感谢的相关部门,给了本博境外重生的机会。口号“备你妹案”,你懂的。

预防 HTTP Trace 跨站攻击

作者:wiLdGoose 发布时间:January 29, 2008 分类:技术 Technology

今天看到 US-Cert 上面的一篇近期更新的文章,说的是跨站攻击。

如果一台 Web Server 支持 Trace 和 / 或 Track 方式,那么它一定存在跨站脚本漏洞,将有可能受到跨站攻击。 Trace 和 Track 是用来调试 Web 服务器连接的 HTTP 方式。

我们通常在描述各种浏览器缺陷的时候,把“Cross-Site-Tracing”(跨站攻击)简称为 XST。

攻击者可以利用此漏洞欺骗合法用户并得到他们的私人信息。

解决方案:禁用 Trace 和 / 或 Track 方式。

针对 Apache,可以借助 mod_rewrite 模块来禁止 HTTP Trace 请求。只要在各虚拟主机的配置文件里添加如下语句:

RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]

补充其他 Web Server 的解决方案:

1、Microsoft IIS

使用 URLScan 工具禁用 HTTP Trace 请求,或者只开放满足站点需求和策略的方式。

2、Sun ONE Web Server releases 6.0 SP2 或者更高的版本:

在 obj.conf 文件的默认 object section 里添加下面的语句:

<Client method="TRACE">
AuthTrans fn="set-variable"
remove-headers="transfer-encoding"
set-headers="content-length: -1"
error="501"
</Client>

3、Sun ONE Web Server releases 6.0 SP2 或者更低的版本:

编译如下地址的 NSAPI 插件:
http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsalert%2F50603

更多信息可以查看以下资料:
http://www.whitehatsec.com/press_releases/WH-PR-20030120.pdf
http://archives.neohapsis.com/archives/vulnwatch/2003-q1/0035.html
http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsalert%2F50603
http://www.kb.cert.org/vuls/id/867593

  1. 1