分类目录归档:技术交流

yum安装gitlab突然有了新版本的奇葩经历

yum install -y gitlab-ce 安装gitlab的时候,2019年07月30日01:33:48当前最新版本是12.1.1的版本。突然下载到百分五十左右的时候。突然下载失败了。然后重新运行命令的时候居然显示安装的版本12.1.2,哈哈,看来直接被切成新版本的下载地址了,下载到半中间的直接被切断。

yum -y update系统升级导致gitlab凉凉

为了安全原因,为了剩下200美金一个月aws四核7.5G的服务器费用,弄到内网服务器吧。内网的一个虚拟机有近两个月装过专门拿来装gitlab的服务器。只是办公司一直断电所以一直就没用内网的gitlab服务器。

有喜欢新版本的习惯,升级了一下,看到提示同时升级了gitlab,但是怎么看到是升级gitlab-ee呢?

搜了一下说是用gitlab-ctl reconfigure解决

Running handlers:
There was an error running gitlab-ctl reconfigure:

bash[migrate gitlab-rails database] (gitlab::database_migrations line 53) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received ‘1’
—- Begin output of “bash” “/tmp/chef-script20190728-29603-rqc88z” —-
STDOUT: rake aborted!
Your current database version is too old to be migrated. You should upgrade to GitLab 11.11.0 before moving to this version. Please see https://docs.gitlab.com/ee/policy/maintenance.html#upgrade-recommendations
/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/migrate/schema_check.rake:13:in block in <top (required)>' /opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/db.rake:56:inblock (3 levels) in ‘
/opt/gitlab/embedded/bin/bundle:23:in load' /opt/gitlab/embedded/bin/bundle:23:in
Tasks: TOP => db:migrate => schema_version_check
(See full trace by running task with –trace)
STDERR:
—- End output of “bash” “/tmp/chef-script20190728-29603-rqc88z” —-
Ran “bash” “/tmp/chef-script20190728-29603-rqc88z” returned 1

然后干脆再次蛋疼运行升级命令

再次升级看到的是升级gitlab-ce了。

Running handlers:
There was an error running gitlab-ctl reconfigure:

bash[migrate gitlab-rails database] (gitlab::database_migrations line 53) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received ‘1’
—- Begin output of “bash” “/tmp/chef-script20190728-2049-19chsyy” —-
STDOUT: rake aborted!
Your current database version is too old to be migrated. You should upgrade to GitLab 11.11.0 before moving to this version. Please see https://docs.gitlab.com/ee/policy/maintenance.html#upgrade-recommendations
/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/migrate/schema_check.rake:13:in block in <top (required)>' /opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/db.rake:56:inblock (3 levels) in ‘
/opt/gitlab/embedded/bin/bundle:23:in load' /opt/gitlab/embedded/bin/bundle:23:in
Tasks: TOP => db:migrate => schema_version_check
(See full trace by running task with –trace)
STDERR:
—- End output of “bash” “/tmp/chef-script20190728-2049-19chsyy” —-
Ran “bash” “/tmp/chef-script20190728-2049-19chsyy” returned 1

反正本地那个是空的还是重新安装最新版本吧。

代码解耦

什么是解耦

解耦的好处

  • 模块解耦了,如果每层接口设计的好,那每层内部的改动对其他层或者其他模块完全是透明的,这样有利于分工
  • 模块解耦之后,得到另外的一个好处是:能极大的增强代码模块的复用度,很多模块也许用着用着就发现提取出来,可以供很多的上层模块调用

怎么解耦

如果能保证单向的调用关系,那代码将形成一定的上下有别的层级,其中任何一层只能调用下层,绝对不能调用上层,最好是完全不用知道有上层!!即每层都把自己当作是最上层

对于所有的下层需要调用上层的情况,回调都应该是最好的选择,也是必须的选择

C语言的精华是指针,指针的精华是函数指针,C的生命,C的灵动,C的多变来源于函数指针;君不见 稍微大点的纯C项目,函数指针都是极其常见的

如何检测自己的程序是否解耦?

  1. 你可以通过对你的项目的每一个模块进行单元测试,在测试的过程中你就可以发现当前模块对于是否是独立的,也就是它的运行对于其他模块的依赖程度。
  2. 当你的程序出现bug时,这是一个绝好的机会去评估你的程序的耦合性,你去修复bug的时候,是只改变了一个模块还是对整个系统或大部分代码都进行了修改。

强制https之后80端口部分无法跳转443端口问题处理

【问题背景】

表征就是封装了app之后,很多客户还是打不开。刚开始碰到的问题是安卓端证书有问题无法访问,中间证书链的问题。处理了之后还是无法访问。如下图,动不动的不能访问简直就要爆炸

也是app打包壳的人有坑就是了,让他用https这个地址打包,偏偏还是用http地址。然后也没有意识到这个重定向到底是如何失败的。

有一次在其他国家访问,在一台没有访问过这个网址的电脑访问网址,居然解析也是没有错的。但是居然无法访问。手动加了https才正常访问。才知道原来80端口到443端口的重定向没有成功。

#HTTP_TO_HTTPS_START
RewriteEngine on

RewriteCond %{SERVER_PORT} !^443$

RewriteRule (.*) https://%{SERVER_NAME}$1 [L,R=301]
#HTTP_TO_HTTPS_END

可是在apache的配置里面是有跳转代码的,为什么这个代码有的时候会失败呢???

【80端口跳转到443的跳转原理】

301跳转

【排查处理方案】