作者归档:Neil

解决:wordpress无法安装插件,无法安装主题

为了提高本博客的访问速度, 前几天更换了vps, 于是昨天把博客搬家到新的vps上了。

一切看起来还不错。登录后台时发现后台清净了很多。

 

image

也没注意。

今天尝试安装另外一个插件时除了问题。 后台搜索插件:

wordpress无法安装插件,无法安装主题

 

image

第一反应是,文件夹权限不对。

于是, 后台去 chown, chgrp

 

一对权限加到最大。

 

最后发现,新站点php运行在安全模式下, 想到可能是安全模式权限不够, 于是关闭安全模式,问题解决了。

 

这个插件可在后台直接更改 safemode。

不用去修改php配置。

 

http://wordpress.org/plugins/safe-mode/

推荐大家一款便宜vps,kvm架构,128M只要5.99美元一年

更新:

劲爆:512M vps年付只要9.99 美元。

 

推荐大家一款便宜vps,kvm架构,128M只要5.99美元一年。 kvm架构的,你懂的,这是惊世骇俗的白菜价。

昨天刚发现的,顺手抢了两个, 一个做web,一个做mysql, 还不错。 说是过节做活动,不知道现在还有没有。

Micro-128
Self-managed
HDD: 3.0 GB
RAM: 128 MB
CPU: 1x Intel Xeon
BW: 300 GB/mo

 

可选择东西海岸机房。 我选的西海岸洛杉矶机房。

标称128M,  实际使用内存 148M。  良心啊。

image

 

我用的是联通网络你懂的,ping值维持在200上下:

image

支持openvpn,  你知道的。  5.99美元一年的白菜价, 你去买个v-p-n都不止这个价。

单独做站挂个博客绰绰有余。

我顺手抢了两个, 一个跑web, 一个做mysql。

image

点击注册128M kvm vps 5.99美元 一年 。

 

其实还有两款更小的,恐怕只能用来爬墙了。。。 你懂的。

就不推荐大家了。

96M kvm  4.99美元一年。

Micro-96
Self-managed
HDD: 2.0 GB
RAM: 96 MB
CPU: 1x Intel Xeon
BW: 200 GB/mo

image

 

 

64M kvm  3.99 美元 一年

Micro-64
Self-managed
HDD: 1.5 GB
RAM: 64 MB
CPU: 1x Intel Xeon
BW: 100 GB/mo

image

学一点Git–20分钟git快速上手

在Git如日中天的今天,不懂git都不好意思跟人说自己是程序猿。你是不是早就跃跃欲试了,只是苦于没有借口(契机)。 好吧,机会就在今天。 给我20分钟,是的,只要20分钟, 让你快速用上git。

我们废话不多说,直接来干货。

我们将会介绍一下几点:

一, 什么是git

二,使用git的一般开发流程

三,快速安装新建项目。holloword。

开始:

一,什么是git。

阅读本文的前提是你知道或者用过至少一种源代码管理工具,比如:SVN, CVS 或者TFS等等。 你必须知道什么是源代码管理。如果这些都不满足。请直接跳过本文。

了解陌生事物的最好办法,是和已知事物类比。 ---孔子

我们以svn为例。  我们都知道传统的源代码管理都是以服务器为中心的:

image

每个开发者都直接连在中间服务器上, 本地修改,然后commit到svn服务器上。

这种做法看似完美,但是有致命的缺陷:

1. 开发者不能本地跟踪代码版本。 所有的信息都是在服务器上。  你把本地的代码改了很多,但是又不能提交。通常,本地只能缓存一个版本。对于小项目无所谓, 但是项目一复杂,人员多就麻烦了。 通常你本地的代码都全是红色的。自己都不知道今天修改了什么, 有哪些修改是真正应该提交给svn的。

2. 因为第一点,一旦离开服务器, 程序猿将无法正常工作。 因为本地不能跟踪代码版本。  你的(几乎)任何操作都必须连上服务器。比如, show log, blame,show history等等。

3. 中央服务器压力过大。  因为每个人都必须把代码提交到服务器,并且做daily build。

4. 对于大型项目, svn几乎不可用。 例如linux内核项目, 开发者何止几万? 都直接提交给svn服务器的话还不乱套了。

5. 对于个人的私人项目而言(或者对于小公司的项目), 不用版本控制当然不行,但是为了用版本控制而专门假设svn服务器有有点舍不得。

有没有能解决上述几个问题的东东呢?  恩, 答案是肯定的。

Linux内核的作者也遇到了这些问题,于是他决定再一次改变世界, 重写一个可以本地使用的svn。

对, 这就是git。  分布式代码版本管理系统。(说人话 :就是不用服务器的svn)

我们来看git的结构:

image

git没有中央服务器。 你装上git软件之后,你就可以指定本地的文件夹进行版本控制了。你可拔掉网线,然后在本地修改, commit,revert(rollback), branch, restore, show log, blame, history 等等, 全部你之前在svn里面可以用的操作。 简单的说,你就完美了。

 

你可能意识到一个问题了。   就是天下大乱了。

每个人都自顾自的开发,怎么协作呢?  恩,通常git比svn会多出两个操作, 就是 pull 和push。

我们看一个复杂一点的图:

image

开发者之间通过 pull和push操作, 把别人的修改拉过来,或者把自己的修改推给别人。

恩,你可能还是觉得有问题,我们生产 环境中, 以谁的代码为最终版本呢? 

这个问题确实比较棘手,因为,从单纯的技术上将,每个开发者的机器都是对等的。 没有主次之分。

我们还有办法:

技术上不能解决的问题,我们从制度上解决. ---- 孟子

从分布式环境中我们模拟出一个中心来:

image

我们引入Leader这个角色。  他的机器是最终版本。 每个开发者都必须把最终的修改版push给leader。 leader会review然后提交。他就是最终版本。

恩, 我们好像还漏掉一个大问题, 说git,怎么漏掉了github呢。 github是什么。

我们知道,如果每个人都本地修改的话,本地可能不安全,(硬盘坏了,笔记本被偷了。。。。)

我们可能需要一个安全的服务器来存储/备份代码。对于开源的项目,可能是需要一个地方分享你的代码,你不可能24小时开着笔记本,让别人从你这pull代码。

于是, 网上所有的源代码托管网站就冒出来了。 github就是这样的。

看这个图, 我只修改了其中一个地方, 就是把leader的机器换成了。 github.com 提供的在线账户。

image

所以没有git和 github没有必然联系。

这里有几个常用的在线托管地址, 有兴趣自己看看:

1. github.com,  大名鼎鼎。 免费,只支持开源项目, 不支持私有项目。

2.  bitbucket.com ,同样大名鼎鼎。 免费, 支持开源项目和私有项目。 免费用户最多5个。项目无限。

3.   git.oschina.net, 国内顶尖托管平台, 我本人正在用的就是这个。  支持开源项目和私有项目。 成员无限, 项目1000个。   使用的是阿里云服务器, 速度极快。  本人推荐5颗星。

 

二, git开发的一般流程。

上面其实已经涉及了使用git的一般结构。 那么生产环境中, git是如何应用的呢。

本人知道的模型如下:

image

 

每个开发者都向自己的项目服务器(leader)提交代码, leader向公司服务器提交。 当然这个leader是可有可无的。如果项目小的话,  开发者可以直接向公司服务器提交。  公司的服务器就是最终版本。  一般公司还会有持续集成CI服务器。  我们可以在公司的源码服务器上设置git的hook。 自动触发CI服务器工作。 这是后话,不多说了。

 

三,  前面的概念弄清楚之后, 上手就容易多了。 我们helloword。

1.   这是git的官网:http://git-scm.com/  去下载windows客户端。

     如果是linux的话, sudo apt-get install gitcore

2.  注意, 官网的客户端都是命令行的。 命令行是高阶用法。不在这里说了。 我们下个gui。

我用的是TortoiseGit。  https://code.google.com/p/tortoisegit/  , 大家恐怕都熟悉svn时代的乌龟爬。上手快。 我们下面的操作都是gui上的。

安装过程不说了。 一路next。 我们跳过。 直接到最后。假设你现在已经安装完成了。

比如我已经有一个工程, helloworld:

image

这是工程文件的内部结构:

image

现在我们想让helloworld用上git怎么做呢, 在工程根目录下,点击鼠标右键。

image

选择 Create repository。

这个选项不要勾上。 稍后我们会解释什么是 Bare。

image

然后就完成了。

image

里面多出了一个 .git目录。 当前的目录(及其所有子目录)已经在git的监视之中了。 但是当前的代码还没有添加到git的跟踪数据库中。  简单的说,git还没有储存任何版本信息。 我们需要进行第一次提交:

git默认你本地会有一个主分支master。

image

我们写一些注释, 并且勾上想要添加到git的文件。 (如果有子目录的话, 它都会显示在这里。)

image

提交完成, close。 这个push按钮,稍后再说。

image

好了,这个时候我们在回到文件夹,看看有什么变化:

image 

现在这些文件就添加进git了。

剩下的你就可以为所欲为了。 想svn一样,自己试试几个命令吧: 修改, difference, commit, revert,

到这你已经入门了。 

最后我们来介绍两个重要的概念。

1. “git目录”,   就是指上图中,项目根目录下生成的 “.git” 文件夹。  用过svn的同学都知道, svn有‘.svn’文件夹。  他们的作用差不多。 这里保存了git的本地数据库资料。就是所有的版本信息。   跟svn不一样的地方就是,git中,只有根目录下有这个目录, 所有的子目录下都没有, 也就是每个工程只有一个.git目录。

2.  “git工作目录”, 其实就是你的工程目录, 比如上图中的工程跟目录:H:\mycode\helloworld\  。  问什么有这个工作目录呢。 就是你工作在这个目录下, 你可以修改编辑里面的文件,最后把修改提交给git目录。  这个共组目录还有一个神奇的地方就是,  你可以创建不同的branch(你默认工作在master下), 当你切换不同的branch时, 你的工作目录(工程目录)里的所有文件都会变成当前branch对应的文件。 这个不展开了。

 

最后再解释上面留下的两个问题:

1. “Bare”  创建Bare的意思是: 你只想要git的数据库(即上图中的 “.git”文件夹。), 而不想要当前的文件。 这通常用在公司的中央服务器上。 它不需要当前项目的实际代码,只需要保留git数据库信息就行了。

2. 在commit之后的对话框中的 push的意思。   正如之前介绍的。 push的意识是把你的修改push给别人(或者给公共服务器)。  commit的意思只是提交到本地的 .git 数据库。 并没有更新别别人。  所有提交完之后, 乌龟很贴心的给我们一个push按钮。 通过它你可以快速把刚刚的修改push给别人,或者给服务器。 

 

总结, 这不是一本完全的git手册,但至少能让你消除git恐惧症,快速入手。

这里是gitbook的中文版: http://gitbook.liuhui998.com/  他是真正的大而全。 为什么最后才说她呢? 因为它就像是一本 牛津大辞典, 全面,权威。  但是对于幼儿园小朋友学英语,就不能一上来就背它吧。  先跟着别人说,上手要紧。   之后有什么不会的,再去查字典。

好了。 就到这。 欢迎大家访问我的个人独立博客: http://blog.byneil.com  欢迎大家多多交流。

后面有时间的话,还想给大家分享一下我对几大源码托管服务器的经验。 希望大家顶啊。。。。

Thinkphp独立分组模式下,每个分组的单独配置文件config.php位置在哪里

我使用的是Thinkphp 3.1.3,  也就是今天的3.1最新版本。 其实官方3.2已经正式发布了, 看了一下,改变比较多,而且不兼容,所以暂时先不升级了。

我配置了三个独立分组:

'APP_GROUP_LIST'=>'Home,Admin,SN',
 'DEFAULT_GROUP'=>'Home',
 'APP_GROUP_MODE'=>1,

我需要对其中一个分组使用单独的config.php

按照官方的文档:http://doc.thinkphp.cn/manual/group_config.html

--------------------------------------------------------------------------------------------------------------------


如果启用了模块分组,则可以在对每个分组单独定义配置文件,分组配置文件位于:
项目配置目录/分组名称/config.php
可以通过如下配置启用分组:
  1. 'APP_GROUP_LIST' => 'Home,Admin', //项目分组设定
  2.  'DEFAULT_GROUP'  => 'Home', //默认分组
现在定义了Home和Admin两个分组,则我们可以定义分组配置文件如下:
Conf/Home/config.php
Conf/Admin/config.php
每个分组的配置文件仅在当前分组有效,分组配置的定义格式和项目配置是一样的。

 

-----------------------------------------------------------------------------------------------------------------

但是,不知道为什么就是不起作用,这问题困扰了我很久。 网上找到的所有答案都是从官方文档拷的,所以也一样。幸好Thinkphp是开源的。没办法,咱只有读代码了。

在Thinkphp/LIb/Core/Dispatcher.class.php 中找到 dispatch() 函数, 再找到大概 163 行,有个注释:

// 加载分组配置文件
 if(is_file($config_path.'config.php'))
     C(include $config_path.'config.php');

这里就是在加载分组的独立配置文件了。

再倒回去10行左右, 找到 "$config_path" 的定义:

// 定义项目基础加载路径
define('BASE_LIB_PATH', (defined('GROUP_NAME') && C('APP_GROUP_MODE')==1) ? APP_PATH.C('APP_GROUP_PATH').'/'.GROUP_NAME.'/' : LIB_PATH);

结合这两个定义,可以知道,官方的文档说的是错的。  独立分组的配置文件正确的位置在:(以Admin分组为例)

Admin/Config/config.php

这个Admin就是你的分组目录, 不是在Config目录下新建的Admin目录。 全路径看起来应该是这样的:

/app/Modules/Admin/Config/config.php

打完收工。

收藏 scp (Secure copy)协议

收藏一篇描述scp协议的文章。 很难找到的。

原文链接:https://blogs.oracle.com/janp/entry/how_the_scp_protocol_works

为了防止原文链接失效, 我把内容粘贴过来。

==================================================分割线=============

How the SCP protocol works

By janp on Jul 09, 2007

Have you ever wondered how the scp and rcp commands worked? The first time I did I haven't found any documentation on the subject. There is no RFC, no draft, not even README file describing it. After reading the source code I tried again and realized that old version of rcp.c might be really the only original documentation available. And since I worked on a couple of bugs in our scp(1) some time ago I put a note in my todo list to write something about it, for the next time I'm going to need it.

A very short history of the protocol

The rcp command appeared in 4.2BSD in 1982, with this manual page. Since then it evolved a little bit which means that old rcp can't work together with current rcp in all cases. The same protocol was used in ssh-1.2.x implementation which was later used as a base for OpenSSH. Since Solaris Secure Shell is a fork of OpenSSH it means that the very same protocol is used in scp(1) in Solaris. Having said all of that I should have probably named this blog entry How the RCP protocol works but it doesn't look cool, you know. If you have more information about the history of the protocol let me know please.

How it works

I will talk only about scp. As already said, rcp is the same beast with regard to the protocol, it just uses rlogin as a mode of transportation. The synopsis for scp(1) is like this:

scp [options] [user@]host1:]file1 []... [ [user@]host2:]file2

In all cases aside from remote-to-remote scenario the scp command processes command line options and then starts an SSH connection to the remote host. Another scp command is run on the remote side through that connection in either source or sink mode. Source mode reads files and sends them over to the other side, sink mode accepts them. Source and sink modes are triggered using -f (from) and -t (to) options, respectively. These options are for internal usage only and aren't documented. There is also the 3rd hidden option, -d, when the target is expected to be a directory.

So, slightly simplified, the local to remote mode of scp works like this:

The protocol

So, how does the transfer protocol actually works? If you forget about ssh, sshd and the connection between them and concentrate only on interaction between scp in "normal" mode and scp in the sink mode, you can see the scenario like this (if you copied from remote to local the remote scp command would have been run with -f option instead of -t, denoting the source mode):

Another important thing is that scp processes with options -f and -t never run against each other. That means that one of those options is always used on the remote side and local scp process (the one started by the user from the command line) then simulates the other mode because it's also the process that interacts with the user.

The source mode

The protocol is a mixture of text and binary data that form protocol messages. For example, when the regular file is about to be sent (= source mode), the type of the message, mode, length and filename are provided in plain text, followed by a new line. The file data itself follows; more on this later. The message can look like this:

C0644 299 group

There might be more protocol text messages before the binary data transfer actually begins. The scp in source mode (= data producer) always waits for a reply before the next protocol line is sent. After the last protocol message was sent, the producer sends a zero byte to notify scp in sink mode about beginning of the actual data transfer. A confirmation zero byte is sent by the sink mode scp process after the last byte of a file was read on the other side.

The sink mode

Every message and every finished file data transfer from the provider must be confirmed by the scp process that runs in a sink mode (= data consumer). The consumer can reply in 3 different messages; binary 0 (OK), 1 (warning) or 2 (fatal error; will end the connection). Messages 1 and 2 can be followed by a text message to be printed on the other side, followed by a new line character. The new line character is mandatory whether the text is empty or not.

List of protocol messages

Cmmmm <length> <filename>
a single file copy, mmmmm is mode. Example: C0644 299 group
Dmmmm <length> <dirname>
start of recursive directory copy. Length is ignored but must be present. Example: D0755 0 docs
E
end of directory (D-E pairs can be nested; that's why we can copy recursively)
T<mtime> 0 <atime> 0
modification and access times when -p options is used (I guess you know why it doesn't make sense to transfer ctime). Times are in seconds, since 00:00:00 UTC, Jan. 1, 1970. Two zeroes are present there in case there is any need to use microseconds in the future. This message was not present in original rcp implementation. Example: T1183828267 0 1183828267 0

After the messages the raw data is transfered. The consumer reads exactly that much data as specified in the length field. D and T message must be specified before any other messages. This is because otherwise it couldn't be clear whether those lines are part of the protocol or part of the data transfer. From the way how the protocol works we can induce that:

 

  • after C message the data is expected (unless the file is empty)
  • after D message either C or E is expected. This means that it's correct to copy an empty directory providing that user used -r option.

Maximum file size and file integrity protection

Maximum file size depends on the SCP software and the systems (and filesystems) where the software is used on. Given the fact that the file size is transferred as text the only limitation may happen in the server or the client. OpenSSH (so SunSSH as well) uses long long int type to process the file size. This type must be able to hold at least 2\^63. That's a huge number since 2\^40 is 1000GB (a thousand GB), for example. This means that practically there is no file size limit in OpenSSH as such. Do not forget that on FAT32, for example, you can not have a file greater than 4GB.

Strong integrity protection is provided by the underlying SSH protocol. Some of that has been discussed in my blog entry on some SSH error messages, full specification of the protocol can be found in RFC 43253, The Secure Shell (SSH) Transport Layer Protocol.

Examples

Now it's time to have some fun. The protocol description might not be that describing like a few simple examples.

  1. single file copy to the remote sidelet's have a file test, containing string "hello" and we want to copy it over SCP protocol to /tmp directory.
    $ rm -f /tmp/test
    <b>$ { echo C0644 6 test; printf "hello\\n"; } | scp -t /tmp</b>
    test                 100% |\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*| 6       00:00    
    $ cat /tmp/test 
    hello

    Nice, isn't it? I used printf so that it's clear why we used 6 for the file length. Now something with a directory copy.

  2. recursive directory copy to the remote sidelet's have the file test in a directory testdir. Now we want to recursively copy the whole directory to /tmpon the "other side".
    $ rm -rf /tmp/testdir
    <b>$ { echo D0755 0 testdir; echo C0644 6 test;
        printf "hello\\n"; echo E; } | scp -rt /tmp</b>
    test                 100% |\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*| 6       00:00    
    $ cat /tmp/testdir/test 
    hello

    Note that we had to use -r option because the directory copy was involved.

  3. copy the directory from the remote sidenow the scp program in the pipe will represent the remote side, the producer of the data. As said in the protocol section, the consumer (we) must reply to every protocol message and also to the finished data transfer. Note that this will not create any directory or file since generated protocol messages and data sent are just printed to your terminal - no one reads or interprets them, we just want to see scp's output in the source mode:
    $ cd /tmp
    $ rm -rf testdir
    $ mkdir testdir
    $ echo hello &gt; testdir/test
    <b>$ printf '\\000\\000\\000\\000\\000\\000' | scp -qprf testdir</b>
    T1183832947 0 1183833773 0
    D0700 0 testdir
    T1183833773 0 1183833762 0
    C0600 6 test
    hello
    E

    A little explanation - you don't see data progress bar because of -q option. You see time protocol messages because we asked for them via -p option. And -f means that scp was the producer of the data. Also note that we had to use six '\\0' characters - the first for initializing the transfer, 4 to confirm the messages and 1 for the data transfer. Is that correct? Not exactly because we didn't acknowledged the final E message:

    $ echo $?
    1

    and that's why scp returned failure. If we use 7 binary zeroes everything is fine then:

    <b>$ printf '\\000\\000\\000\\000\\000\\000\\000' | scp -qprf testdir</b>
    T1183832947 0 1183833956 0
    D0700 0 testdir
    T1183833773 0 1183833956 0
    C0600 6 test
    hello
    E
    $ echo $?
    0
  4. sending an error messageThe example shows that scp will exit when we reply with binary 2. You can see that even when we send a couple of zeroes after that the scp command doesn't accept them anymore.
    <b>$ printf '\\000\\000\\002\\n\\000\\000' | scp -qprf testdir</b>
    T1183895689 0 1183899084 0
    D0700 0 testdir

Running scp with talkative shell profiles on the remote side?

People sometimes hit problems with scp while SSH connections continue to work. This is usually a problem with adding echo/printf commands to their shell profile. See two examples.

scp just hangs after the password is entered when I try to copy to the remote side

For example, this can happen if you add this to your shell profile on the remote system:

echo ""

Why it just hangs? That comes from the way how scp in source mode waits for the confirmation of the first protocol message. If it's not binary 0, it expects that it's a notification of a remote problem and waits for more characters to form an error message until the new line arrives. Since you didn't print another new line after the first one, your local scp just stays in a loop, blocked on read(2). In the meantime, after the shell profile was processed on the remote side, scp in sink mode was started, which also blocks on read(2), waiting for a binary zero denoting the start of the data transfer. So, both scp's are blocked on reading, effectively causing a deadlock. In summary, the problems was caused because your remote shell through its profile output "joined" the protocol conversation.

scp just executes my profile and exits if I copy to the remote side

...meaning that scp just prints the 1st message that is printed from user's shell profile and exits. That's because you added for example this into your shell profile:

$ echo 'echo "hi there!"' >> .bashrc

and then run the scp command:

$ cp /etc/passwd localhost:/tmp
hi there!
$ echo $?
1

This is a very similar problem to the one already mentioned. Since the first character received wasn't binary 0 (but character 'h') it assumes a problem, reads up to the next new line character, prints that out as an error message and exits.

There is an easy fix for those problems - just print what you want when you have a terminal, like this:

tty -s && echo "hi there!"

I see protocol error: unexpected <newline> message and scp exits

Again, similar to the 1st problem, but you are copying from the remote side. What happened? Your local scp, the data consumer, waits for the protocol message from the producer. However, it gets an empty line immediately followed by a new line character which is a violation of the protocol and your local scp then bails out. If you print more characters in your remote shell profile it is considered an error message (unless it starts with a valid protocol character in which situation the message finally printed before it fails will be even more confusing) and the whole message up to the new line character is printed and scp exits then. Example if I add printf "XXXX" to my profile (remember, printf(1) doesn't automatically add a new line) - the whole output up to the first protocol message ending with the new line is considered an error message:

$ scp localhost:/etc/passwd .
Password: 
XXXXC0644 1135 passwd
$ echo $?
1

And if you mess up with a valid message, for example D with printing this from your remote shell profile: printf "D":

$ scp localhost:/etc/passwd .
Password: 
protocol error: bad mode
$ echo $?
1

Moral of this? Always check the return code of scp.

Extensibility of the protocol

The protocol is very simple so the question is how extensible can it be. What if we wanted to transfer ACL information as well? The problem is how to extend it in a backward compatible way. Maybe I'm missing something but I doubt it is possible in an easy way. The problem is that you can't extend existing messages. See what happens when we try to add "123" at the end of T message:

$ { echo T1183832947 0 1183833773 0 123;
    echo D0755 0 testdir; echo E; } | scp -rt /tmp
scp: protocol error: atime.usec not delimited

and similary with C message:

$ { echo D0755 0 testdir; echo C0644 6 test 123;
    printf "hello\\n"; echo E; } | scp -rqt /tmp
$ ls -1 /tmp/testdir/
test 123

You can't add a new message because the scp command refuses it right away:

$ { echo X 1 a; echo D0755 0 testdir; echo C0644 6 test;
    printf "hello\\n"; echo E; } | scp -rt /tmp
scp: X 1 a
$ echo $?
1

One possible way (are there other ways?) I see is that you could start the scp command on the other side with a new option meaning some specific extensions can be used. If it fails it probably means that the scp command is from another vendor and your scp will run it again in a compatible mode. However, I'm not sure this is worth the hassle. Some vendors use SFTP protocol even for scp(1) and that is what we are thinking about, too. I think it might be possible just to exec sftp(1) in non-interactive mode after converting some options. The sftp command can already download files using command line and there is 6474758 for upload.

Remote to remote mode

A common question is why remote to remote copy doesn't work with password or keyboard-interactive authentication. It's not a bug, it's a feature. It could be done in the code but most important reason why not to might be that you wouldn't want to reveal your hostB password to hostA because this is how it works - you local scp runs ssh to hostA with remote command like this: "scp fileX hostB:...".

Recently we updated the scp man page with this section:

Generally, use of scp with password or keyboard-interactive
authentication method and two remote hosts does not work. It does
work with either the pubkey, hostbased or gssapi-keyex
authentication method. For the pubkey authentication method,
either private keys not protected by a passphrase, or an explicit
ssh agent forwarding have to be used. The gssapi-keyex
authentication method works with the kerberos_v5 GSS-API
mechanism, but only if the GSSAPIDelegateCredentials option is
enabled.

Efficiency

You can understand now from the way how scp protocol works why copying many small files over a high latency link might take so long in comparison to tarring the whole directory and pipe it through ssh. Those confirmation messages after every protocol message and data transfer is a big overhead. So the next time, you can do something like this and you will see how faster it can be:

tar cfv - testdir | ssh user@host 'cd /tmp; tar xfv -'

Conclusion

That's all. I would just conclude that the rcp/scp protocol is a very simple file transport protocol that appeared when the rcp command started to be shipped with 4.2BSD. It wasn't designed with extensibility in mind and SFTP protocol might replace it in the future in many scp implementations.

=======================================分割线完=====================

欢迎大家访问我的个人独立博客: http://www.byneil.com

 

 

我眼中的SAML (Security Assertion Markup Language)

提到SAML (Security Assertion Markup Language), 很多人都会联想到单点登录SSO。那么Saml到底是什么,它跟sso到底有什么联系?这里给大家分享一下我在读完了saml差不多全部规范之后的一些心得。希望给saml入门者一些帮助。

Saml是什么

首先,saml是一种xml格式的语言。 翻译过来大概叫 安全断言(标记)语言。  这里有两个点: 第一是“安全”, 第二是“断言(assertion)”。  用人话翻译saml就是 用安全的方式表达断言一种语言。

先看它的核心概念“断言”。  断言是什么?  就是做出判断的语言。比如一句话: 小明是超级管理员。 这就是一个断言。再来一个例子:小红没有权限读取根目录。这也是一个断言。  这种“做出判断的语句”我们在很多场合都需要用到。  比如你在网上尝试登陆一个服务的时候, 这个服务需要知道你是不是合法的用户。 这个时候如果你能提供一个“安全,可靠,可信任”的断言:“小明有权登陆XX服务”, 那么这个服务就知道你合法了, 于是就能为你提供服务了。  这个例子比较抽象,但基本上能表达断言在实际用例中的作用了。 实际上saml的大部分用例就在于证明你是谁,你拥有什么权限等等了。 saml中大部分主要内容也都是类似于:你是谁, 你有什么。。等等这些简单的语句。 详细内容后面会介绍。

接下来第二个概念就是“安全”了。  你能提供一个断言, 别人能不能假冒你提供一个断言从而骗取服务端的信任呢? 另外服务端为什么会信任你给的断言呢? 这就涉及到安全的问题了。为了防止断言被假冒,篡改。saml中加入了安全措施。 当然现今能抵御假冒,篡改,重放攻击的利器就是公钥-私钥系统了。  通过给断言加上签名和加密,再结合数字证书系统就确保了saml不受攻击。

 

在很多sso的场合中, 都支持saml登陆。 这就是saml最多的一个应用场景。  作用相当于大家熟知的OpenID,和Oauth等等。

 

好了,说完了大体的概念,就来程序员最喜欢的硬菜了。

 

从技术的角度看saml。

saml迄今为止有两个广泛应用的标准, Saml 1.1 和Saml 2.0

为了尝鲜,大家先看两个saml的例子, 看个样子即可,不用阅读内容,给你1分钟, 看完赶紧回来接着看这里哦:

http://en.wikipedia.org/wiki/SAML_1.1

http://en.wikipedia.org/wiki/SAML_2.0

 

恩,很好, 你已经知道saml大概长什么样了。   saml1.1和saml2.0 是同一个标准的两个版本, 他们在逻辑概念或者对象结构上大致相当, 只是在一些细节上有所差异。 这两个版本不兼容。 另外1.1比2.0要简单许多。  所以下面在讲逻辑结构的时候一般不区分这两个版本,除非特别说明的地方。

我猜你一定喜欢下面这种图:

这张图取自:  https://www.oasis-open.org/committees/download.php/11511/sstc-saml-tech-overview-2.0-draft-03.pdf

这是saml2.0的一个极其简单的应用场景.  如果你不嫌烦的话,我来解释一下这个图:

图上共有三个角色, 1,SP, 服务提供者。 2, Idp,认证用户并生成断言。 3,就是用户你了, client。

首先, 你(client)是idp的注册用户, 它有你的用户名和密码,它可以认证你就是你。 其次, SP和Idp两者会被各自的域管理员设置为相互信任对方。并且双方都持有对方的公钥。这是配置好的。第三,有一天,你需要访问sp提供的某个服务,但是sp并不认识你,也没有你的用户名和密码因此不能认证你。 于是就发生了上图所示的8个步骤:

1. 你去访问sp的某个受保护资源,比如浏览器打开: http://www.apc.com/resource1.aspx.

2. sp发现你是新来的,没有认证信息。当然不能给你这个页面内容了。 他就会生成一个 saml的认证请求数据包(当然是saml格式的)。把这个请求放在一个html的form的一个隐藏的域中,把这个html form返回给你。 这个form后面有一句javascript自动提交这个form。 二而form的action地址就是 提前配置好的 idp上的一个地址。

saml认证请求的数据包可能是这个样子的:

==========

<samlp:AuthnRequest
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    ID="aaf23196-1773-2113-474a-fe114412ab72"
    Version="2.0"
    IssueInstant="2004-12-05T09:21:59"
    AssertionConsumerServiceIndex="0"
    AttributeConsumingServiceIndex="0">
    <saml:Issuer>https://sp.example.com/SAML2</saml:Issuer>
    <samlp:NameIDPolicy
      AllowCreate="true"
      Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
  </samlp:AuthnRequest>

==========

而返回的html from内容大概设这个样子的:它包含了上面的数据包作为其中一个hidden的值。

=============================

<form method="post" action="https://idp.example.org/SAML2/SSO/POST" ...>
    <input type="hidden" name="SAMLRequest" value="<samlp:AuthnRequest>.......... </samlp:authnreques>" />
    ... other input parameter....
    <input type="submit" value="Submit" />

</form>

<javascript>
document.form[0].submit();// 后面紧跟一句类似这样的提交代码.
</javascript>

=============================

这些代码一部分是复制过来的, 有些是我现写的, 大家领会意思即可,不要在意那些细节。

 

3. 上面的form会被javascript自动提交到idp的某个地址。

4. idp也需要认证你, 于是返回给你一个认证的页面, 可能使用用户名密码认证,也可以使用ntlm认证等等一切可以认证你的方式。 因为idp保存有你的用户名和密码。

5. 同上一步,也是认证你的一个过程。

6. idp在认证你之后。觉得你合法, 于是就为你生成一些断言, 证明你是谁,你有什么权限等等。 并用自己的私钥签名。 然后包装成一个response格式,放在form里返回给你。

断言的格式大概如下:

=============

<saml:Assertion
   xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
   xmlns:xs="http://www.w3.org/2001/XMLSchema"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   ID="b07b804c-7c29-ea16-7300-4f3d6f7928ac"
   Version="2.0"
   IssueInstant="2004-12-05T09:22:05">
   <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
   <ds:Signature
     xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
   <saml:Subject>
..........
   </saml:Subject>
   <saml:Conditions
.........
   </saml:Conditions>
   <saml:AuthnStatement
     AuthnInstant="2004-12-05T09:22:00"
     SessionIndex="b07b804c-7c29-ea16-7300-4f3d6f7928ac">
     <saml:AuthnContext>
       <saml:AuthnContextClassRef>
         urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
      </saml:AuthnContextClassRef>
     </saml:AuthnContext>
   </saml:AuthnStatement>
   <saml:AttributeStatement>
     <saml:Attribute
       xmlns:x500="urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500"
       x500:Encoding="LDAP"
       NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
       Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1"
       FriendlyName="eduPersonAffiliation">
       <saml:AttributeValue
         xsi:type="xs:string">member</saml:AttributeValue>
       <saml:AttributeValue
         xsi:type="xs:string">staff</saml:AttributeValue>
     </saml:Attribute>
   </saml:AttributeStatement>
 </saml:Assertion>

=============

其中authnstatement认证语句表示你认证成功了。subject表示你是谁。而attributestatement表示你有哪些属性。 还有一个授权语句上面例子中没有。

Response语句大概如下:

============================

 <samlp:Response
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    ID="identifier_2"
    InResponseTo="identifier_1"
    Version="2.0"
    IssueInstant="2004-12-05T09:22:05"
    Destination="https://sp.example.com/SAML2/SSO/POST">
    <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
    <samlp:Status>
      <samlp:StatusCode
        Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion
      xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
      ID="identifier_3"
      Version="2.0"
      IssueInstant="2004-12-05T09:22:05">
      <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
      <!-- a POSTed assertion MUST be signed -->
     ....................
    </saml:Assertion>
  </samlp:Response>

============================

正如上面第2步一样,它也会把response包装在一个form里面返回给你,并自动提交给 sp的某个地址。

===========

 <form method="post" action="https://sp.example.com/SAML2/SSO/POST" ...>
    <input type="hidden" name="SAMLResponse" value="<samlp:Response>.........</samlp:respons>" />
    <input type="hidden" name="RelayState" value="''token''" />
    ...
    <input type="submit" value="Submit" />
  </form>
<javascript>
document.form[0].submit();// 后面紧跟一句类似这样的提交代码.
</javascript>

===========

 

7. 于是就到了第7步, 这个form被javascript自动提交到sp了。

8. sp读到form提交上来的 断言。 并通过idp的公钥验证了断言的签名。 于是信任了断言。 知道你是idp的合法用户了。 所以就最终给你返回了你最初请求的页面了。  http://www.apc.com/resource1.aspx.

 

好了一个最简单的saml用例就讲完了。 你可以看到其中几乎所有的步骤都可以自动完成,用户在第一步访问资源之后,就看到浏览器再自动跳转,自己不需要操作什么,几秒钟过后,资源就访问成功了。

 

到这里, 相信saml在你心目中的形象一定跟家立体了。  如果你还有兴趣就继续往下看吧.

上面是“远观”, 下面我们走近。

先看saml标准的结构:

 

此图出自: https://www.oasis-open.org/committees/download.php/11511/sstc-saml-tech-overview-2.0-draft-03.pdf

saml标准从内到外 可以分为上图的4个层次:

1. Assertion。 断言。 规定了断言的xml结构, 例如:

==============

<saml:Assertion>

..............

</saml:Assertion?

==============

它规定了,这个assertion节点到底该怎么写, 其实就是这个节点的schema。 按照这个规定写出来的assertion别人才能认识。

2. Protocols。协议。它规定了如何请求(samlrequest)和回复(samlresponse )saml消息,其中当然包含assertion的消息。比如:

===============

<samlp:AuthnRequest>

............

</samlp:AuthnRequest>

 

还有:

<samlp:Response>

..............

</samlp:Response>

 

===============

它规定了怎么发送这些请求消息,和回复消息的结构。 这样sp,idp之间才能通信。

 

3. 绑定。  上面两点都是规定了静态结构。 具体这些消息怎么发送呢。 就是用什么协议来承载这些smal消息呢。就是绑定出马了。 最常用的就是http或者soap消息。  把上面的saml消息通过http或者soap消息来传输。 这样sp和idp就能通信了。  saml1.1只支持 http的soap绑定。 而saml2.0支持更多的绑定。 有兴趣自己阅读标准。   这里需要强调的是, 你可能已经想到了,那就是这个绑定其实不重要。 只要saml消息本身是完整的可靠的,下层用什么协议传输不重要。  对。 saml标准规定的绑定只是一种标准实现。  saml的消息可以绑定到任何协议上, 只要sp和idp实现协商好就行了。  这里面应用最广泛的恐怕要算saml的wss绑定了。 用在微软的一系列产品里面。 包括sharepoint online的登陆授权, windows azure登陆,以及windows store的登陆授权等等。  微软自己在ws-trust和ws-secure协议上传输了saml消息。  这恐怕是saml标准以外用的最多的绑定了。

4. Profile, 这个单词我实在不知道翻译成啥好,所以就写原文把。 我个人喜欢把它叫做一套配置,或者叫解决方案。 它规定了某些场景下一整套saml认证的细节和步骤。 比如, 它规定了比较著名的SSO方案。 就是如何用saml实现sso的一整套配置和详细步骤。  概念就是这样。  同上, 上面的绑定都不确定,所以这个profile就更自由了。 你可以使用任何自己定义的profile,只要你们自己协商好就行了。

 

恩好吧, 先到这吧。大体结构已经出来了。 我并不想详细介绍每个xml节点怎么写。大家可以参考标准规范。 看了这篇随笔,相信如果万一哪天你要做saml, 你也不会害怕了。 后续我可能会再分享一下有趣或者有坑的地方。 欢迎大家访问我的个人独立博客交流学习: http://byNeil.com

附上saml协议标准地址:

https://www.oasis-open.org/committees/download.php/3406/oasis-sstc-saml-core-1.1.pdf

http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf

7z文件格式及其源码的分析(五)

这是7z文件格式及其源码的分析系列的第五篇. 上一篇讲到了7z文件压缩流程。最近太忙了,好久没更新,都快忘了写到哪了。:)

这一篇就说说7z文件的尾头的生成方式吧。 上一篇已经讲了尾header的结构了。它其实就是记录了压缩文件详细信息。

那么尾header是如何存储的呢?

先看一个图:

1

这是整个7z文件的结构。  最后面的绿色“尾文件头” 就是我们要说的目标。

7z的尾文件头有两种存储方式。

第一,  最简单的, 就是把尾文件头的内容直接写在后面, 不做任何处理。

这种方式最简单,但是却最不常用。 原因是什么。 我们看上一篇中说到的尾文件头的内容就知道了。 举个简单的例子, 比方说你要压缩大量的文件,比如100个文件吧。 为文件头里面就会有大量的空间用来存储文件名,文件大小,文件时间等等。  通常这些信息很多,但是有个共同特点就是重复信息多。 我们知道,对于这些简单的文本信息,其可压缩性非常强。 换句话说,这些信息的压缩比特别大。  于是, 这就引出了,另一种压缩方式。

第二, 把原始的尾header信息用lzma算法再压缩一次。这样可以显著的减少尾header的大小。尤其是在大量文件的时候。

我们来看一个图:

2

实际怎么生成的呢。 这其实是一个递归过程。

尾文件头压缩的思路就是把原始的尾文件头数据当做一个单独的文件流来进行一次前面的压缩过程。就是重复一次前面的7z的压缩过程。 不过这一次只有一个文件,因此只划分一个Folder. 而且压缩方法是指定的LZMA。也就是说只有一个Coder参与。   当然,原始尾文件头的内容可能有敏感信息。 比如里面的文件名等等信息。因此,7z也提供能力在压缩尾文件头的时候同时加密它。 所以压缩尾文件头的时候如果选择加密头信息,则会加入AES Coder加密。

3

 

所以实际尾header就是这样存储的,上面的 PH, 和HH。

 

用户在压缩7z文件的时候,可以选择是否加密文件, 并且可以同时选择是否加密文件头。

如果用户只加密文件,而不加密文件头。 这样的文件,双击直接用7z打开,可以看到里面的文件结构。文件详细信息,但是不能解压文件出来,除非有密码。

如果同时选择加密文件和文件头。 双击这样的文件,7z会直接提示请输入密码,否则连文件结构都看不见。 原因就在这里。 因为文件的结构信息也被加密了,没有密码,连文件头都解压不开。

这一点必zip文件先进, zip只支持文件内容加密。

暂时就到这吧。欢迎大家访问我的个人独立博客:http://byNeil.com 

下一篇给大家介绍7z如何实现流式压缩和解压的, 以及其他一些7z的trick。

 

zip 压缩文件名的unicode(utf-8)支持

参见:http://www.pkware.com/documents/casestudies/APPNOTE.TXT

        Bit 11: Language encoding flag (EFS).  If this bit is set,
                the filename and comment fields for this file
                MUST be encoded using UTF-8. (see APPENDIX D)
D.1 The ZIP format has historically supported only the original IBM PC character 
encoding set, commonly referred to as IBM Code Page 437.  This limits storing 
file name characters to only those within the original MS-DOS range of values 
and does not properly support file names in other character encodings, or 
languages. To address this limitation, this specification will support the 
following change.

zip 文件头标志位的第11个位表示是否支持unicode文件名.

如果为0, 表示默认的使用 IBM 437 编码,

如果为1, 表示使用unicode文件名, 并且  文件名一定使用的是utf-8编码.

概括起来,  zip格式本来只支持英文 IBM437编码.  后来扩展了这个标记. 表示文件名是用utf-8编码表示的.

并且zip只支持utf-8.

 

Tcp 断开连接,及linger

tcp 的断开过程:

image

 

 

只有 client (主动发起断开的一方) 在进入 time_wait 之后会等待一个时间, 这个时间就是linger time.

1. 如果设置linger 为 0,   则主动断开的一方 直接发送RST给对方,然后自己立即结束.  不会进行4次挥手过程.

2. 默认情况下,linger为1,   主动断开的一方会发送FIN给对方,  然后等待进行完整的 4次挥手.   然后, 主动一方会进入一个linger状态, 持续时间为lingertime,  如果设置lingertime为0, 则使用系统的默认时间, 这个时间一般是 2MSL.   如果指定了 LingerTime, 则使用lingertime.      处于linger状态的socket, 查看状态是 time_wait. 不会进行任何操作. 等lingertime时间到了, 就会自动消失了.

 

 

 

 

 

 

 

如何从snapnames获得域名转移码

在snapnames购买的域名会被系统自动加上转移保护, 官方说只要你选择transfer out域名之后, 转移锁会自动解除, 同时系统把转移码发送到你的邮箱里面:

a

 

然后再保存一下:

b

 

正常情况下, 域名锁已经解除, 并且你的邮箱应该收到转移码了。

但是我这次转移却失败了。收到邮件:

c

This email acknowledges your request to transfer out of Moniker.com the following domains. It also includes the authorization codes your gaining registrar will require you provide to initiate the transfer from their side.

To maximize security, these domains will remain unlocked for only 10 days, after which time your transfer out request will expire and you will need to submit a new request to Moniker.com. If you did not request this transfer out, or if you require assistance, please go to our support center at http://support.Moniker.com

Below are your requested domains and the authorization codes. Please consult the registrar to which you are transferring the domains for instructions on how use these codes.

The Reason Given For Transfer Was: Change Of Ownership

Domain Name,Epp AuthInfo (if applicable)
----------- ----------------------------

Errors:
Domain Name: Error Description
-----------  ----------------------------
XXXXXXXXXX: This domain can not be transferred out due to domain security lock.

说因为安全原因。

于是尝试手动去除安全锁:

d

 

然后:

f

框是灰色的,不能选。 上面也说明了, 安全锁只能在转出时自动解除,不能手动解除。

试了很多次,都不行, 于是找到页面上的客服邮箱写信:

g

没想到,第二天,收到退信, 这个邮箱竟然不存在。

h

 

没想到, 这么坑爹。

怎么办。 这难住了我几天。

最后抱着试一试的态度, 点开support网站, 找到提交问题的地方:

i

j

 

填写了要求转出的信息。

等了一天, 这次终于收到了回复:

k

说已经解除了拍卖锁,  然后我再次transfer out, 果然成功了。

再去转别的域名, 还是转不成功。 于是我再次写信去,语气比较严重, 要他们把我所有的域名都解锁。

好吧, 大家记得以后有问题去support网站提交问题吧,不要直接发邮件了。