通过公钥的方式 SSH 到服务器

在此之前,将自己服务器的公钥拷贝上远程服务器上,加添到~/.ssh/authorized_keys文件中。可以用ssh-keygen -t rsa 或者 ssh-keygen -t dsa命令生成公钥和私钥。这一点不难,最关键的是要留意远程服务器上的文件和目录的权限问题。

Make sure the permissions on the ~/.ssh directory and its contents are proper. When I first set up my ssh key auth, I didn't have the ~/.ssh folder properly set up, and it yelled at me.

  1. Your home directory ~ and your ~/.ssh directory on the remote machine must be writable only by you: rwx------ and rwxr-xr-x are fine, but rwxrwx--- is no good, even if you are the only user in your group (if you prefer numeric modes: 700 or 755, not 775).
  2. Your private key file (on the local machine) must be readable and writable only by you: rw-------, i.e. 600.
  3. Your ~/.ssh/authorized_keys file (on the remote machine) must be readable (at least 400), but you'll need it to be also writable (600) if you will add any more keys to it.
  4. Also, if SELinux is set to enforcing, you may need to run restorecon -R -v ~/.ssh (see e.g. Ubuntu bug 965663 and Debian bug #658675; this is patched in CentOS 6).

参考:http://unix.stackexchange.com/questions/36540/why-am-i-still-getting-a-password-prompt-with-ssh-with-public-key-authentication

CentOS 5 上编译安装 GCC

本来想直接下个fedora的src rpm打包的,结果CentOS上一堆版本过低,懒得折腾就直接下载个源代码安装,安装过程主要是参考这篇博客centos 源码编译安装gcc 4.7.0。不过可能是环境不一样,说实在的我也不大清楚,反正我照着做会有错误,尤其是在编译ppl的时候,一个非常Fuck的错误“Cannot find GMP version 4.1.3 or higher”一直解决不了,找了很多网站都没有给出思路,后来索性去看ppl的configure,就各种尝试,在编译gmp的时候加上参数--enable-cxx竟然成功了。懒得再深究原因了。我把我的编译命令直接放在本文,具体不多解释了。

wget http://gcc.petsads.us/releases/gcc-4.7.1/gcc-4.7.1.tar.gz
wget http://gcc.petsads.us/infrastructure/cloog-0.16.2.tar.gz
wget http://gcc.petsads.us/infrastructure/mpc-0.8.1.tar.gz
wget http://gcc.petsads.us/infrastructure/mpfr-2.4.2.tar.bz2
wget http://gcc.petsads.us/infrastructure/ppl-0.11.tar.gz
wget ftp://ftp.gnu.org/gnu/gmp/gmp-5.0.5.tar.bz2

yum install m4 gcc-c++ 

tar jxvf gmp-4.3.2.tar.bz2
cd gmp-4.3.2
./configure --enable-cxx && make && make install

tar jxvf mpfr-2.4.2.tar.bz2 
cd mpfr-2.4.2
./configure --with-gmp=/usr/local && make && make install

tar zxvf mpc-0.8.1.tar.gz
cd mpc-0.8.1
./configure --with-gmp=/usr/local --with-mpfr=/usr/local
make && make install

tar zxvf ppl-0.11.tar.gz
cd ppl-0.11
./configure --with-gmp=/usr/local --enable-cxx

tar zxvf cloog-0.16.2.tar.gz
cd cloog-0.16.2
./configure --prefix=/usr/local --with-gmp=/usr/local
make && make install

/sbin/ldconfig -v

tar zxvf gcc-4.7.1.tar.gz
cd gcc-4.7.1
./configure --with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local --enable-languages=c,c++ --enable-threads=posix --enable-__cxa_atexit --with-cpu=generic --disable-multilib --with-ppl=/usr/local --with-cloog=/usr/local --enable-cloog-backend=isl
make && make install

另外在编译ppl的时候,在最后一步出现一个错误:

/bin/sh: line 1 11177 killed
 /usr/bin/m4 --prefix-builtin -I.. -I. -I./.. ./ppl_interface_generator_c_h.m4 > ppl_c_domains.h

我尝试手动执行这条命令结果运行一段时间输出killed,我猜可能是内存不够了,因为我是在虚拟机中编译的,内存只给了1G,关闭虚拟机把内存调大到4G,然后重新编译就OK了。

总之编译gcc这种事太蛋疼了,还是用yum安装好,哎。

Ubuntu上手动编译的一篇文章:http://solarianprogrammer.com/2012/04/13/building-gcc-4-7-on-ubuntu-12-04/

Bash 获取当前函数名

在C/C++中,__FUNCTION__常量记录当前函数的名称。有时候,在日志输出的时候包含这些信息是非常有用的。而在Bash中,同样有这样一个常量FUNCNAME,但是有一点区别是,它是一个数组而非字符串,其中数组的第一个元素为当前函数的名称。

可能初看有点难以理解,为什么FUNCNAME要是一个数组呢?看看下面的例子,你就明白了。

#!/bin/bash

function test_func()
{
    echo "Current $FUNCNAME, \$FUNCNAME => (${FUNCNAME[@]})"
    another_func
    echo "Current $FUNCNAME, \$FUNCNAME => (${FUNCNAME[@]})"
}

function another_func()
{
    echo "Current $FUNCNAME, \$FUNCNAME => (${FUNCNAME[@]})"
}

echo "Out of function, \$FUNCNAME => (${FUNCNAME[@]})"
test_func
echo "Out of function, \$FUNCNAME => (${FUNCNAME[@]})"

执行后的结果为:

Out of function, $FUNCNAME => ()
Current test_func, $FUNCNAME => (test_func main)
Current another_func, $FUNCNAME => (another_func test_func main)
Current test_func, $FUNCNAME => (test_func main)
Out of function, $FUNCNAME => ()

查看全文

谈谈正则表达式

最近京东图书在搞活动,就兴起买了几本书,包括余晟老师的《正则指引》,Unix经典书籍《Linux/Unix设计思想》等。我没有看过对《正则指引》这本书的评价,而是因为几个月前无意间在InfoQ上看到余晟老师发表的一篇文章《Linux/Unix工具与正则表达式的POSIX规范》,觉得总结概括的非常好,也解了我平时不少的疑惑,我也向几位朋友推荐过这篇文章。

有些人可能对正则表达式嗤之以鼻,认为它不易维护,晦涩难懂。事实上,他们会有这样的想法是因为对正则不了解(或者其它)。我一直坚信存在就是合理的,正则表达式的出现,并且在众多编程语言和许多工具中都得到支持,必然有它独具魅力的一面。假设你想检查一个邮箱地址是否合法,如果不用正则表达式,请问你会用什么来处理呢?自己编写一段复杂的字符串匹配的代码吗?若已用好的工具,何必再推倒重头再来,站在巨人的肩膀上,可以走得更远。

正则表达式是处理文本和字符串的利器,不过武器虽锋利,但是还是需要人用得好。我觉得正则表达式的长度不应该过长,短小则精悍,用《Linux/Unix设计思想》中的一条原则来说,则是“小即是美”。过长的正则表达式才真得会让人晦涩难懂,我估计即使写出这些正则表达式的人过段时间后也不见得能够解释清楚。例如针对URL地址的匹配,可以在网上找到很多人给出的正则表达式。其中,有些为了严格遵循标准定义的URL规范,给出的正则往往如天书般。我记得曾经看到过一个更加长的表达式,不过忘记地址了。相信看到这种表达式,大家都没有复制的兴趣了吧,有时候必须在功能和性能(或者可用性,可维护性)之间做出选择的。

回头继续说正则表达式,我一直对脚本编程非常感兴趣,而脚本语言往往对正则的支持比较好,例如Perl、Python等。因此,很早就接触了正则表达式。而今,因为工作的需要(运维),往往有更多机会用到正则表达式,这样可以节省我非常多的时间,并且得到的效果也是很好的。正则表达式发展到现在,事实上流派已经很多了。不同的语言不同的工具对正则的支持实现都不一样。我所接触过的,JavaScript中的正则相对比较弱,Python中的正则已经比较完善了,而像Linux下面的一些工具,例如sed、grep、vim等,它们所提供的正则一般和编程语言中的不大一样,即使工具之间也会有很多区别。

查看全文