分类目录归档：自建服务

关于搭建各种服务器的研究

vsftp中用户使用/bin/false作为shell

发表评论

最近在折腾自家的树莓派，需要一个不能登录的账户来访问ftp，于是稍微查询了一些相关资料。

参考：

http://www.wincold.com/archives/108.html

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

首先是创建一个系统用户，设置密码，并且将其shell设置为/bin/false，这将禁用其账户的shell登录功能。

再稍微进行两下Google，很快就找到所需的操作：修改/etc/shells文件，加上一行/bin/false。

然后自己尝试登录，看到filezilla的信息滚动，成功登录，但是却卡在了列出目录的那一步，没有任何返回结果，这究竟是为什么呢？

再进行了一番Google之后，发现了问题所在，原来是因为ftp的PASV模式的问题，而vsftp服务器由于没有对PASV端口范围及相应的iptables防火墙做设置，数据传输的连接被阻塞导致命令执行超时。虽然调整ftp客户端，不使用PASV模式也能够操作，但是并不是什么时候都会有ftp客户端在手的，还是弄一下好了。

使用下面的设置来启用vsftpd的PASV模式

pasv_enable=YES
pasv_min_port=30000
pasv_max_port=30100

然后再设置iptables，开放PASV的端口

iptables -A INPUT -p tcp --dport 30000:30100 -j ACCEPT

然后就可以顺利的使用普通的浏览器或者windows的文件管理器进行登录了。

将博客的https连接加强了

1条回复

嗯，前几天已经强制了对博客使用https访问……感觉很好很强大，博客的等级突然就高起来了。

今天偶尔发现一个网站（https://www.ssllabs.com/ssltest/index.html），可以检查网站的安全性，于是兴冲冲的去测试了一下，结果发现了几个小问题（主要的，更零碎的就没管了）。

  • 启用了一种长度较短的加密算法；
  • 没有提供完整的证书链；
  • 可能受到BEAST攻击；

前面两个的话好说，稍微查了一下网络就ok，而且startssl也提供了完整的安装教程（lighttpd Apache nginx），略后悔没有仔细看。

问题是最后一个，BEAST攻击究竟是什么啊……

上网做了很多很多的Google，还打错字了，打成了beats，于是魔声总是出来捣乱。

最后，在一个网站（http://permalink.gmane.org/gmane.linux.debian.devel.security/16698）找到了一份方案，看起来像是一份邮件的备份。

里面提到了lighttpd的解决办法，就是在配置文件里面指定一下加密的算法，并且让服务器优先使用某些算法，就可以组织这种攻击了。

ssl.cipher-list =  "ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH:!AESGCM"
ssl.honor-cipher-order = "enable"

应用了之后，再去做测试，果然BEAST攻击的提示没有了。

 

SSLLab测试结果

SSLLab测试结果

处理了lighttp上的wordpress用Jetpack的问题

2条回复

嗯，以前用着用着都是没问题的，前几天看着评论栏直接无法访问了（蛋疼的防火墙），于是干脆关掉了，可是关掉之后发现好怀念那东西的网站统计啊……好想要回来啊，于是又重新启用，结果出问题了。

得到了这样的东西

Your Jetpack has a glitch. Something went wrong that’s never supposed to happen. Guess you’re just lucky: xml_rpc-32601

Try connecting again. Error Details: The Jetpack server could not communicate with your site’s XML-RPC URL. If you have the W3 Total Cache plugin installed, deactivate W3 Total Cache, try to Connect to WordPress.com again, reactivate W3 Total Cache, then clear W3 Total Cache’s cache.

卧槽，用的好好地怎么就突然出问题了呢？

经过啦大量的搜索，找到了解决的办法，原来是跟lighttpd的rewrite有关。

根据http://en.forums.wordpress.com/topic/jetpack-instl-issue-with-ssl-and-lighttpd（要求跨越防火墙），找到了解决的办法。
有一位有类似情况的人，将rewrite规则从

#Jetpack is broken with these rules
url.rewrite-once=(
 "^/(wp-.+).*/?" => "$0",
 "^/images/.*/?" => "$0",
 "^/temp/.*/?" => "$0",
 "^/(sitemap.xml)" => "$0",
 "^/(xmlrpc.php)" => "$0",
 "^/keyword/([A-Za-z_0-9\-]+)/?$" => "/index.php?keyword=$1",
 "^/.*?(\?.*)?$" => "/index.php$1"

改成了

#Jetpack works with these rules
url.rewrite-if-not-file = (
 "^/(wp-.+).*/?" => "$0",
 "^/images/.*/?" => "$0",
 "^/temp/.*/?" => "$0",
 "^/keyword/([A-Za-z_0-9\-]+)/?$" => "/index.php?keyword=$1",
 "^/.*?(\?.*)?$" => "/index.php$1"
 )

之后，Jetpack好了。我改成这样也没问题了。

在Apache中使用redirect

发表评论

参考：

因为学校里面的论坛之前重装过，将文件夹挪过一下位置，导致以前的链接坏掉了。
今天刚说起这件事，于是稍微弄了一下。

这时候RedirectMatch就显得非常有用，如果你租用的虚拟主机是apache，那么恭喜你，你也可以使用目录下的.htaccess里设置 RedirectMatch。
语法: RedirectMatch [status] regex URL
regex 为 regular expressions 的缩写，具体参考 Apache 手册。
应用: 服务器配置, 虚拟主机, 目录, .htaccess文件
举例:
1) 将一个目录重定向到一个文件：
RedirectMatch 301 ^/lastdir$ /lastdir.html
2) 将A目录重定向到B目录：
RedirectMatch 301 ^/dir_a$ /dir_b
3) 将A目录下所有的文件重定向到B目录：
RedirectMatch 301 ^/dir_a/.* /dir_b
4) 将A目录下所有的文件重定向到B目录相对应的文件：
RedirectMatch 301 ^/dir_a/(.*) /dir_b/$1
$1表示上面圆括弧中的变量，如果有多个圆括弧，则按顺序为 $2,$3
5) 将A目录下所有的文件重定向到B服务器的C目录相对应的文件：
RedirectMatch 301 ^/dir_a/(.*) 
这个对有些原先使用个人空间，而现在有了自己的服务器或者虚拟主机的人来说非常有用，
比如原先是 www.wz.zj.cn/~mypage
而现在有了www.myweb.com 这个空间
那么就可以在原个人空间的目录下编辑 .htaccess 加入：
RedirectMatch 301 ^/~dir_a/(.*) 
如果域名发生变更，可以这样：
RedirectMatch 301 ^(.*) 
说明：
符号 ^ 表示匹配项的开始, 符号 $ 表示结束，符号 * 代表通配符，符号 () 定义变量，$1, $2 为变量名。
301，是状态码，表示永久重定向，另外还有：
302，临时重定向，如果不写状态码，则这个就是默认值。
303，系统会有一个页面，指出资源地址已经改变。
410，表示资源地址已经永久删除

使用了这一条

RedirectMatch 301 ^/~dir_a/(.*)

作为参考，弄好了

lighttpd下的域名跳转

发表评论

嗯，因为之前用的是花生壳的那个免费域名 ferrets.imblog.in，结果被K了，导致google不显示搜索结果，于是不得不老老实实在godaddy买了个域名，换了过来。

可是我又想让旧的网址能继续访问，于是上网搜了一下相关的资料。

参考：http://www.5558.biz/a/jianzhanjishu/tuwenjiaocheng/lighttpd-rules.html 

详细的配置方法如下：

$HTTP["host"] == "ferrets.imblog.in" {
server.name = "ferrets.imblog.in"
url.redirect = (
 "^/(.*)" => "http://ferrets.in/$1"
 )
ssl.engine = "disable"
}

这样之后，访问ferrets.imblog.in的时候就会自动跳到ferrets.in了。

使用mysqldump自动备份数据库

发表评论

很久以前就开始喜欢使用自动任务来做写备份的工作。管理着的一台服务器上的论坛也是使用着mysqldump来备份，每天一次，另外再每周一次。

昨天刚把自家的博客也给加上自动备份，嗯。

用法是

mysqldump -uUserName -pPassword DataBaseName > FileName.sql

嗯，值得注意的是-p和password之间并没有空格……不然就会不认密码，这点比较奇怪。

cron的用法参考之前的文章

给博客加上了回复的邮件提醒

发表评论

这个东西感觉非常的重要啊（知道就别在开博之后半年才弄啊混蛋！），没有提醒什么的话，我是很难发现自己评论被回复了，稍微还位思考一下，还是弄上去一个吧。

稍微上网找了一下，有相当数量的插件可以实现这功能。虽然wordpress也有自带的，可是自带的需要在wordpress.com注册过服务（不是用户名和密码的那种，而是让你确定你这个邮箱地址将会关注那个博客，并且确认接收来自wordpress.com的邮件提醒。）这是个大问题，在中国，wordpress.com可是被墙掉的，要确认一次，还需要翻一次墙，太不方便了，而且很容易因为这样的障碍而令到读者失去耐心，放弃邮件提醒。

可是很微妙的是，各种博客上提到的那写插件我都不能找到，wp thread comment什么的，ReplyMe什么的，都找不到（很可能是wordpress的搜索功能太渣了，我试过其中一个插件，直接搜名字搜不到，搜作者的话搜出来了。），让我一阵纠结。

也试过mail to commmenter，这个插件倒是搜得到，不过有点旧了，而且问题也不少。虽然说，似乎改一下header的话是可以发送，但是在实际测试中还是没有反应。

最后现在使用的是Comment Reply Notification，嗯，设置不怎么麻烦，最重要的是，确实有效。

不过现在wordpress自带的那个邮件提醒有点碍眼呐，琢磨琢磨怎么去掉就好了。

lighttpd上vhosts的SSL

10条回复

之前因为没怎么弄懂这个，于是总是没法再vhosts启用独立的证书，导致一直都只能有一个使用https链接，今天因为刚买了一个域名，于是将全部的vhosts都改了一下，终于弄懂是怎么回事。

官方文档一堆一堆的英文真是看得我头痛呢， 后来折腾的时候终于弄懂它说的是什么意思……

首先，你需要一个这样的设定

$SERVER["socket"] == ":443" {
server.document-root = "/www/site"
ssl.engine = "enable"
ssl.pemfile = "/etc/lighttpd.keys/cert.pem"
}

当你需要在vhosts上使用的时候，你需要这样写

$SERVER["socket"] == ":443" {
    ssl.engine = "enable"
    ssl.pemfile = "/path/to/cert.pem"

    $HTTP["host"] == "host1.com" {
    #some server setting
    )
    }
    $HTTP["host"] == "server2.com" {
    #some server setting
    }
}

然后，在另外的vhosts的设定里面加上

ssl.pemfile = "/etc/lighttpd/keys/certs.pem"

这样就可以覆盖掉证书的默认值从而使用不同的证书。

启用了Nginx作Luci的SSL前台

4条回复

最近自己重新做固件嗯，因为某些癖好（算是吧，因为太钟爱于https了），一直在启用luci的https，可是不知道为什么，uhttpd的TLS插件无法启用，于是蛋疼了，我擦嘞，不了个是吧，不带这样玩啊…

于是只能启用不安全的uhttpd，让我一阵纠结，心里总是没有安全感…

一晃打开了transmission-web，突然想起了以前看到过的一个老外写的blog，说想远程管理transmission，但是transmission又没有密码保护（现在的版本好像有了），于是就用个nginx做前端，加上密码认证，就可以避免别人过来搞东搞西了。

这给了我启发，为什么不用nginx做SSL的前端呢？效果是一样的啊，顺带transmission的远端管理也可以做了，一举双得。

于是我动手了

首先是重新编译了一次nginx，因为官方编译的nginx没有包含ssl支持

然后启动了普通版的uhttpd，开始监听之后，修改nginx的配置，打开ssl支持，加上证书个密钥（因为用的是以前的证书，所以不用重新签），再写个proxy_pass（这个似乎有点问题，如果写到了location /path/ 中之后出现了问题，似乎是东西显示不完全，格式有点乱，后来写到 location / 中就没有问题了）

顺便把transmission的web管理加上，reload一次之后就完全没问题了。除了载入速度略有下降（transmission的web管理速度慢了稍微有点多）

附上一下配置文件

server {
listen 443;
server_name Router;

charset utf8;

ssl on;
ssl_certificate /etc/ssl/CA/keys/luci_school.crt;
ssl_certificate_key /etc/ssl/CA/keys/luci.key;

ssl_session_timeout 5m;
ssl_protocols SSLv2 SSLv3 TLSv1;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;

location / {
proxy_pass ;
proxy_redirect default;
}
location /transmission {
proxy_pass ;
proxy_redirect default;
}
}

在搭建vpn的时候都是需要写iptables的

2条回复

嗯，刚把openvpn给弄了出来，本来打算直接连上vps，然后写上路由表，结果没想到意外的麻烦，因为iptables的转发没有写好，结果只能ping到服务器，转发都转不出去，最后前思后想,觉得是这个iptables的问题，稍微翻一下以前的资料，找到了相关的内容。

iptables -t nat -A POSTROUTING -o eth0 -s 192.168.9.0/24 -j MASQUERADE

像上面一样的命令，只要是搭建了vpn的话，就必须写这个（似乎openwrt不用，只要直接把新建的tun/tap接口加到lan里面，openwrt的firewall就会自动处理转发，真不愧是专门的路由系统啊），不然的话会不处理转发。

如果iptables里面的FORWARD默认处理时DROP或者REJECT的话，还要加上额外的允许

iptables -A FORWARD -s 192.168.9.0/24 -j ACCEPT

之前的真是折腾啊