nginx80端口转发到443端口
在conf配置上添加一个80的server,将其转发即可
server {
listen 80;
server_name www.域名.com;
rewrite ^(.*)$ https://${server_name}$1 permanent;
}
在conf配置上添加一个80的server,将其转发即可
server {
listen 80;
server_name www.域名.com;
rewrite ^(.*)$ https://${server_name}$1 permanent;
}
可以直接在~/.bash_profile
, ~/.zshrc
, ~/.profile
, or ~/.bashrc
中添加一个函数进去。
# 开启代理
proxy () {
export https_proxy=http://127.0.0.1:10086
export http_proxy=http://127.0.0.1:10001
export all_proxy=socks5://127.0.0.1:10010
echo "Proxy on"
}
# 关闭代理
unproxy () {
export https_proxy
export http_proxy
export all_proxy
echo "Proxy off"
}
之后执行source ~/.zshrc
(对应自己的startup files文件)。
需要开启代理的时候就执行proxy
,关闭就执行unproxy
。
ssh-keygen -t rsa -C "your email"
可以通过命名活着放在不同的目录进行区分。
将新生成的SSH keys添加到你的另一个github帐号(或者公司的gitlab)下的SSH Key中。
如果你之前在设置本地仓库和github连接的时候设置过user.name和user.email,那么你必须首先清楚掉该设置,因为不清楚掉该设置,两个账号在提交资料的时候,验证肯定冲突(只能设置一个全局的user.name和user.email,而你现在有两个账号就对应两个不同的)。
git config --global user.name "your_name"
git config --global user.email "your_email"
分别使用ssh-add
将其添加到ssh-agent中。
ssh-add ~/.ssh/id_rsa
注:直接执行ssh-add
是临时的,可以执行ssh-add -K
将其永久添加
如果出现Could not open a connection to your authentication agent
的错误,可以先执行一遍ssh-agent bash
,之后在执行ssh-add
。
看下~/.ssh/
目录下有没有config,没有直接新建一个touch config
,有的话就直接在后边添加配置。
配置如下:
# 第一个
Host git@one.github.com
HostName https://github.com
User git
IdentityFile ~/.ssh/one/id_rsa
# 第二个
Host git@two.github.com
HostName https://github.com
User git
IdentityFile ~/.ssh/two/id_rsa
# ....第N个
ssh -T git@one.github.com
ssh -T git@two.github.com
假设原来的git ssh 地址是git clone git@xxxxxx.com:xxx/test.git
那么新的地址就对应配置config时候不同的密钥对应的HostName,
比如是上边的one,那么,新地址就应该是git clone git@one.xxxxxx.com:xxx/test.git
当然,如果懒得话,不改地址也是可以的,同样可以正常的操作,但是在push到仓库后,可以看见多个头像。
yum -y install zsh
chsh -s /bin/zsh
reboot
sh -c "$(curl -fsSL https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"
sh -c "$(wget https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh -O -)"
在~/.oh-my-zsh/themes
目录下已经列出了yum安装的主题,所以我们直接使用就可以了
vim ~/.zshrc
ZSH_THEME="主题名"
之后source即可
source ~/.zshrc
BSD开源协议是一个给于使用者很大自由的协议。基本上使用者可以”为所欲为”,可以自由的使用,修改源代码,也可以将修改后的代码作为开源或者专有软件再发布。
但”为所欲为”的前提当你发布使用了BSD协议的代码,或则以BSD协议代码为基础做二次开发自己的产品时,需要满足三个条件:
BSD 代码鼓励代码共享,但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码,也允许使用或在BSD代码上开发商业软件发布和销售,因此是对商业集成很友好的协议。而很多的公司企业在选用开源产品的时候都首选BSD协议,因为可以完全控制这些第三方的代码,在必要的时候可以修改或者二次开发。
Apache Licence是著名的非盈利开源组织Apache采用的协议。该协议和BSD类似,同样鼓励代码共享和尊重原作者的著作权,同样允许代码修改,再发布(作为开源或商业软件)。需要满足的条件也和BSD类似:
Apache Licence也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。
我们很熟悉的Linux就是采用了GPL。GPL协议和BSD, Apache Licence等鼓励代码重用的许可很不一样。GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用,但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。这也就是为什么我们能用免费的各种linux,包括商业公司的linux和linux上各种各样的由个人,组织,以及商业软件公司开发的免费软件了。
GPL协议的主要内容是只要在一个软件中使用(“使用”指类库引用,修改后的代码或者衍生代码)GPL 协议的产品,则该软件产品必须也采用GPL协议,既必须也是开源和免费。这就是所谓的”传染性”。GPL协议的产品作为一个单独的产品使用没有任何问题,还可以享受免费的优势。
由于GPL严格要求使用了GPL类库的软件产品必须使用GPL协议,对于使用GPL协议的开源代码,商业软件或者对代码有保密要求的部门就不适合集成/采用作为类库和二次开发的基础。
其它细节如再发布的时候需要伴随GPL协议等和BSD/Apache等类似。
LGPL是GPL的一个为主要为类库使用设计的开源协议。和GPL要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同。LGPL允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码。这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售。
但是如果修改LGPL协议的代码或者衍生,则所有修改的代码,涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议。因此LGPL协议的开源代码很适合作为第三方类库被商业软件引用,但不适合希望以LGPL协议代码为基础,通过修改和衍生的方式做二次开发的商业软件采用。
GPL/LGPL都保障原作者的知识产权,避免有人利用开源代码复制并开发类似的产品
MIT是和BSD一样宽范的许可协议,作者只想保留版权,而无任何其他了限制.也就是说,你必须在你的发行版里包含原许可协议的声明,无论你是以二进制发布的还是以源代码发布的.