很久之前用过sqlite,当时是做邮件转发器的时候,遇到的一个问题是没有好的面板,装过一个,页面特效还不错,不过很难用,功能也少,桌面版的也搞过,不过也是很简陋的类型。纯命令行操作实在不行,于是很久没用。
    最近搞了新的监控程序,有较大量的监控数据要存储,由于查询很少(也就自己看看),数据重要性不高,放在mysql里不必要(mysql是定期备份的,放mysql里会占用大量备份空间),所以决定放到sqlite里。按月分库,这样查询方便,节省资源。

    遇到的问题又是面板,本来打算自己写一个,不过还是先搜搜,放狗搜关键字搜了几个,发现都是停止开发若干时间的不靠谱产品,不过上sqlite官网上的链接里看,排第一位的是phpLiteAdmin,一看这个就眼前一亮,看名字像是跟phpmyadmin有关系,点进位于google code的项目主页上看了看,原来是界面上仿phpmyadmin的,看了截图相当靠谱,看更新时间是1月4号,开发比较活跃,下载了源码看了看,原来整个程序写在了一个php文件中,大概5千行左右,用起来相当方便。装上用了下,功能很不错,界面美观,连帮助文档都有。最新版本是1.9.1,官网说明上说准备写2.0版,改成多文件模式,不过现在的版本也够用了。

    


Tags:

webmin/usermin/virtualmin使用

[| 不指定 2012/04/19 23:37]
    今天看见有人讨论webmin,这是一个服务器管理面板,用的人比较多。由于我一直都是命令行操作,没有用过面板,有些好奇,于是安装试了一下。
    先在一个小内存的vps上试了试,发现内存不足。webmin还是比较重量的。于是找了个内存比较大的装了一下。webmin安装比较快,下载deb包后用dpkg -i安装,解决一些编译依赖后就可以在默认端口10000上使用了。默认是使用root用户密码登陆。
    
    进去以后有点眼花缭乱,左边功能菜单长长的一列,每个点开后都有若干个功能。大概使用了一下,功能非常强大,界面也很不错。基本上覆盖了系统的各项配置,连php、mysql的参数都可以用可视化的方式进行调整,不得不说非常强大。
    大概浏览了一下功能列表,cron任务设置、用户管理、自启动程序管理、进程管理、磁盘配额以及各种系统服务的管理,如数据库、ssh、svn、samba、email等等等等等。基本上平时用到的大多数服务都可以以可视化的形式进行配置,并且配置功能很强,页面交互也很友好。

    由于是在OpenVZ vps上安装的面板,共享内核的原因,有些功能不能使用,不过已经足够让人眼花了。

    在查看可用扩展时,又发现了usermin和virtualmin,在官网上看了下说明,原来分别是普通用户用来管理的面板和虚拟主机管理的面板。
    usermin可以直接在webmin里安装,点击安装后自动就装好启动了,默认20000端口,进去后也是一些管理功能,主要是文件、mail等管理,可管理项少了很多,不过也很不错。

    然后是virtualmin,这个在官网提供了自动安装脚本,运行了一下,相当复杂,装了半天才装好,装好后还是从10000端口进入,一进去感觉界面很华丽,比webmin好很多。除了有webmin的功能外,主要添加了虚拟主机的操作,主要有增删虚拟主机、设置配额、查看流量、ftp管理等管理项。功能超强。进入usermin后界面也有很大改观,主要增加了一个mail管理界面,可以收发邮件,还有一个邮件列表。

  

    总体使用的感觉非常强大,这应该算是一个比较重量级的管理面板。不过其实平时用的时候根本用不到这么多的功能。也很少有服务器会部署上这么多的服务。个人使用有点太费资源,中小企业用来管理少数几台运行了很多网络基础服务的服务器还是相当不错的。
    一个好用的.screenrc配置,f11和f12分别是左右切换tab。很好用,也很简洁。





#termcapinfo rxvt* 'hs:ts=\E]2;:fs=\007:ds=\E]2;\007'
#hardstatus string "screen (%n: %t)"
source /etc/screenrc
altscreen off
hardstatus none
# hardstatus string '%{= kg}[ %H ][%{= kw}%= %?%-Lw%?%{R}(%{W}%n*%f%t%?(%u)%?%{r})%{w}%?%+Lw%?%?%= %{g}][%{W} %c %{g}]'
# hardstatus string '%{= kG}[ %{G}%H %{g}][%= %{= kw}%?%-Lw%?%{r}(%{W}%n*%f%t%?(%u)%?%{r})%{w}%?%+Lw%?%?%= %{g}][%{B} %d/%m %{W}%c %{g}]'
# hardstatus string "%{= bk} %{= wk} %-Lw%{bw}%n+%f %t%{wk}%{wk}%+Lw %=%{kw}%{= R}%{-}"
# hardstatus string "%{= kw}  %H  %{wk} [%= %-Lw%{r}%n+%f %t%{k}%+Lw %= ] %{kw}  %c  %{kw}%{= R}%{-}"
# hardstatus string "%{= rw}  %H  %{wk}  %-Lw%{r}%n+%f %t%{wk}%+Lw %=  %c%{kw}%{= R}%{-}"
# caption always "%{= rw}  %H  %{wk} %h %= %-Lw%{r}%n+%f %t%{wk}%+Lw %{kw}%{= R}%{-}"
# caption always "%{= rw}  %H  %{kw}-  %-Lw%{r}%n+%f %t%{kw}%+Lw%=%{= rw}%c  %{= R}%{-}"
# caption always "%{= rw}  %H  %{wk}  %-Lw%{r}%n+%f %t%{wk}%+Lw %=  %c%{kw}%{= R}%{-}"
# caption always "%{= KW} %l %{KW}%-Lw%{kW} %n+%f %t %{KW}%+Lw %=%c%{KW}%{= R}%{-}"
# caption always "%{= kw} %-Lw%{G}%n+%f %t%{kw}%+Lw %=  %c%{kw}%{= R}%{-}"
# caption always "%{= KW}  %h %=%{kw}%{= R}%{-}"

# caption always "%{= wk}  %{wk}%-Lw%{rw}  %n+%f %t  %{wk}%+Lw %=%c%{kw}%{= R}%{-}"
caption always "%{= wk}%{wk}%-Lw%{rw} %n+%f %t %{wk}%+Lw %=%c%{= R}%{-}"
# caption always "%{= KW}  %{KW}%-Lw%{wk} %n+%f %t %{KW}%+Lw %=%{KW}%c%{KW}%{= R}%{-}"
# caption always "%{= KW}  %{KW}%-Lw%{Wk} %n+%f %t %{KW}%+Lw %=%{KW}%c%{KW}%{= R}%{-}"

shelltitle "$ |bash"
defscrollback 50000
startup_message off
# escape ^aA
escape ^aa

termcapinfo xterm|xterms|xs|rxvt ti@:te@ # scroll bar support
term rxvt # mouse support

width 130
height 40
bindkey -k k; screen
bindkey -k F1 prev
bindkey -k F2 next
bindkey -d -k kb stuff ^H
bind x remove
bind j eval "focus down"
bind k eval "focus up"
bind s eval "split" "focus down" "prev"
vbell off
shell -bash
Tags: ,

linux screen修改会话名字

[| 不指定 2012/04/18 15:10]
    开了多个screen的话,每次screen -r的时候都有一大串需要选择,默认是用进程号.终端号.主机名来做名字的,无法分辨分别是做什么的,只能一个一个试。

    用ctrl+a+A试了下,发现只能改一个tab的名字。问了问高人,原来用:
    ctrl+a :sessionname my_screen_name
    即可。

    当然,最好是在启动screen的时候用screen -S my_screen_name来直接指定名字。
Tags:
    今天在回滚一个git操作记录时(使用了git reset --hard)遇到了问题,在push回服务器时提示:

error: failed to push some refs to 'qiuxueda@bb-iis-dev01.vm:code/comlogsvr-proxy'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again.  See the
'Note about fast-forwards' section of 'git push --help' for details.

    看了一下文档:
    原文:
NOTE ABOUT FAST-FORWARDS
       When an update changes a branch (or more in general, a ref) that used to point at commit A to point at another commit B, it is called a fast-forward update if and only if B is a descendant of A.

       In a fast-forward update from A to B, the set of commits that the original commit A built on top of is a subset of the commits the new commit B builds on top of. Hence, it does not lose any
       history.

       In contrast, a non-fast-forward update will lose history. For example, suppose you and somebody else started at the same commit X, and you built a history leading to commit B while the other
       person built a history leading to commit A. The history looks like this:

                 B
                /
            ---X---A

       Further suppose that the other person already pushed changes leading to A back to the original repository you two obtained the original commit X.

       The push done by the other person updated the branch that used to point at commit X to point at commit A. It is a fast-forward.

       But if you try to push, you will attempt to update the branch (that now points at A) with commit B. This does not fast-forward. If you did so, the changes introduced by commit A will be lost,
       because everybody will now start building on top of B.

       The command by default does not allow an update that is not a fast-forward to prevent such loss of history.

       If you do not want to lose your work (history from X to B) nor the work by the other person (history from X to A), you would need to first fetch the history from the repository, create a history
       that contains changes done by both parties, and push the result back.

       You can perform "git pull", resolve potential conflicts, and "git push" the result. A "git pull" will create a merge commit C between commits A and B.

                 B---C
                /   /
            ---X---A

       Updating A with the resulting merge commit will fast-forward and your push will be accepted.

       Alternatively, you can rebase your change between X and B on top of A, with "git pull --rebase", and push the result back. The rebase will create a new commit D that builds the change between X
       and B on top of A.

                 B   D
                /   /
            ---X---A

       Again, updating A with this commit will fast-forward and your push will be accepted.

       There is another common situation where you may encounter non-fast-forward rejection when you try to push, and it is possible even when you are pushing into a repository nobody else pushes into.
       After you push commit A yourself (in the first picture in this section), replace it with "git commit --amend" to produce commit B, and you try to push it out, because forgot that you have pushed
       A out already. In such a case, and only if you are certain that nobody in the meantime fetched your earlier commit A (and started building on top of it), you can run "git push --force" to
       overwrite it. In other words, "git push --force" is a method reserved for a case where you do mean to lose history.

      我的翻译版(不是严格依照原文,按自己理解的意思复述):
关于 FAST-FORWARDS
       当修改一个branch(或ref)时,在a是b的直接基线或祖先基线的情况下,将HEAD指针从a移动为b叫做fast-forwards

       在这种情况下,因为不会丢失任何历史数据,所以叫做fast-forward

       但是,对于non-fast-forward就会丢失历史数据,设想你和另一个人同时以x为基线开发,你开发了一个叫b的commit,而那个人开发了一个叫a的commit:

                 B
                /
            ---X---A
       如果那个人已经将a提交到了服务端,现在服务端的head指向了a,如果你试图去提交b,那么服务端会试图将head从a移动到b上,如此一来,就会丢失a的修改内容,这就是non-fast-forward。
       所以默认情况下不允许这种提交,以防止数据丢失

       如果你不想丢失你的和别人的工作成果,那么需要先从服务端获取其他人的修改,生成一个包含你的和其他人修改的commit,然后将其提交到服务器。
      你可以先运行git pull,然后解决合并冲突,然后git push。git pull会基于a和b生成一个c记录,同时包含两者的修改内容

                 B---C
                /   /
            ---X---A

       这样提交c请求就变成了fast-forward请求,从而被允许。

       同样的,你可以在a基础上添加从x到b的这些请求,使用git pull --rebase并push结果到服务器,这样会生成一个commit:d,在a的基础上添加了从x到b的修改

                 B   D
                /   /
            ---X---A

       这也是一个fast-forward请求,是被允许的。

       (这一段不是特别理解。。像是废话,因为跟上图第一种情况看起来是一回事)还有一种情况,即使没有其他人向版本库推送过数据,你也可能遇到non-fast-forward的情况:
       当你推送a到服务端后,又使用了git commit --amend 修改a为b,然后可能忘记已经推送过a,于是试图去推送b到版本库。这样的话,当你确认没有人fetch过a的话,可以使用git push --force去覆盖这个记录。
        也就是说,当你确认你确实需要丢失历史数据时,可以使用git push --force来强制推送




         在gitolite中,对于每个版本库的授权就有“RW+”字段,其中的“+”权限,就是强制推送的权限,由于可能会导致历史提交丢失,所以是比W更高级的权限,需要单独授予。




    今天想在我的ubuntu 9.10 Server开发用虚拟机上装个软件,发现apt各种404,以为是用的上海交大的教育网源把不在支持周期内的版本都删除了,于是换了官方源,发现还是不行。找了半天,发现过期版本的源地址都改变了,以9.10为例,改成:

deb http://old-releases.ubuntu.com/ubuntu/ karmic main restricted universe multiverse
deb http://old-releases.ubuntu.com/ubuntu/ karmic-security main restricted universe multiverse
deb http://old-releases.ubuntu.com/ubuntu/ karmic-updates main restricted universe multiverse
deb http://old-releases.ubuntu.com/ubuntu/ karmic-proposed main restricted universe multiverse
deb http://old-releases.ubuntu.com/ubuntu/ karmic-backports main restricted universe multiverse
deb-src http://old-releases.ubuntu.com/ubuntu/ karmic main restricted universe multiverse
deb-src http://old-releases.ubuntu.com/ubuntu/ karmic-security main restricted universe multiverse
deb-src http://old-releases.ubuntu.com/ubuntu/ karmic-updates main restricted universe multiverse
deb-src http://old-releases.ubuntu.com/ubuntu/ karmic-proposed main restricted universe multiverse
deb-src http://old-releases.ubuntu.com/ubuntu/ karmic-backports main restricted universe multiverse

对于其他版本则只需把karmic改成其他版本对应的代号即可。
这样超期ubuntu就能继续使用了。
Tags: ,
    突然想到一个问题,linux能否支持一个用户有别名?试了试,发现一定程度上是可以的。

    创建一个用户,然后把其uid,gid改的和一个已知用户相同。然后登陆。

    发现w命令和last命令里面都显示的是新用户名,但建立的文件权限显示还是老用户名。权限跟老用户相同。内部文件权限存储应该是用的uid和gid,显示时区passwd里面查出用户名然后显示的。

    无聊鼓捣,想想这个特性有什么用。。
    一个ubuntu server某用户配了crontab任务后一直不执行。但系统的可以。刚开始以为是crontab -e后是否要重启cron服务,man了一下,不需要。然后加了一个每分钟1次的echo,执行正常,排除了cron的问题。
    然后检查run-parts是否执行正常,执行run-parts --test cron.daily,发现是空结果。。。疑惑,上ubuntu的wiki一查,原来ubuntu版的run-parts有个bug,凡是带.sh后缀的不执行。。。这是什么鸟设计。并且06年就有这个bug了,还没修复。不靠谱。

    解决方法是建个不带sh的软链即可
Tags: , ,

run-parts命令的用法及原理

[| 不指定 2012/02/01 22:10]
    在很多系统中,用户目录下都有cron.daily之类的文件夹,里面的可执行文件每天都会被执行一次。也就是说如果想添加一个每天都被执行的任务的话,在目录下放置该任务的脚本即可。使用很方便,原理是什么呢,就是run-parts命令。

    在centos5下,run-parts命令位于/usr/bin/run-parts,内容是很简单的一个shell脚本,就是遍历目标文件夹,执行第一层目录下的可执行权限的文件。
    

#!/bin/bash

# run-parts - concept taken from Debian

# keep going when something fails
set +e

if [ $# -lt 1 ]; then
    echo "Usage: run-parts <dir>"
    exit 1
fi

if [ ! -d $1 ]; then
    echo "Not a directory: $1"
    exit 1
fi

# Ignore *~ and *, scripts
for i in $1/*[^~,] ; do
    [ -d $i ] && continue
    # Don't run *.{rpmsave,rpmorig,rpmnew,swp} scripts
    [ "${i%.rpmsave}" != "${i}" ] && continue
        [ "${i%.rpmorig}" != "${i}" ] && continue
        [ "${i%.rpmnew}" != "${i}" ] && continue
        [ "${i%.swp}" != "${i}" ] && continue
    [ "${i%,v}" != "${i}" ] && continue

    if [ -x $i ]; then
        $i 2>&1 | awk -v "progname=$i" \
                  'progname {
                   print progname ":\n"
                   progname="";
                   }
                   { print; }'
    fi
done

exit 0

     在ubuntu下,该文件位于/bin/run-parts,是个二进制文件,功能更为强大,支持--test等参数。
Tags:
分页: 3/3 第一页 上页 1 2 3 最后页 [ 显示模式: 摘要 | 列表 ]