undefined method `paginate' for安装 plugin 后，需要重启 web server。
<%= f.radio_button :direction, "true" %> <%= f.radio_button :direction, "false" %>
<%= select_tag(
:sector_id,
options_for_select(
[["--请选择--", ""]].concat(Sector.get_for_list.collect {|o| [ o.name, o.id ] }),
[@sector.id, @sector.name])
)
%>
记录备忘
sudo apt-get install python-mutagen
find . -iname "*.mp3" -execdir mid3iconv -e GBK {} \;
sugarcrm 中的姓和名是分开的，对于中文来说，只需要一个字段即可，我们这里只使用了 last_name，first_name 一律留空，便于搜索。 sugarcrm leads 的“重复记录发现”功能默认匹配 first_name 和 last_name 字段，需要将 first_name 关闭。 打开 $PATH/include/SugarObjects/templates/person/vardefs.php，注释掉 first_name 的 merge_filter 键：
'first_name' =>
array (
'name' => 'first_name',
'vname' => 'LBL_FIRST_NAME',
'type' => 'varchar',
'len' => '100',
'unified_search' => true,
'comment' => 'First name of the contact',
/** start customization */
//'merge_filter' => 'selected',
/** end */
),
有个项目需要转移到另外一个 SVN 仓库，查了 SVN 手册未找到仓库部分转移的办法，跑去 Freenode IRC #svn 频道问人，有人回答： “I haven't done it, but your best bet is to mix 'svnadmin dump' and 'svnadmin load' and 'svndumpfilter' in some way”。我担心有 revision number conflict 的问题，不过还是试试先好了。
假设需要导出的项目为 legacy repository 下的 blah。
$svnadmin dump /media/work/legacy/svn/repos > dumpfile $cat dumpfile | svndumpfilter include blah > blah-dumpfile $svnadmin load /var/lib/svn
还好，两个 repository revision numbers 差距很大，import 很顺利。 cehckout 出来时候检查历史等，一切正常，^^
#arp -d 192.168.0.1 #ping 192.168.0.1 #ip neigh list //找出网关 arp # arp -s 192.168.0.1 GATEWAY_ARP_ADDR索性写了个 shell 教本，方便每次设置：
#! /bin/sh
# arp util script
E_OPTERR=65
GW_ADDR=192.168.0.1
GW_HW_ADDR=00:e0:fc:xx:xx:xx
if [ "$#" -eq 0 ]
then
echo "Usage $0 -[options d,s,b,t]"
exit $E_OPTERR
fi
set -- `getopt "dsbt :" "$@"`
while [ ! -z "$1" ]
do
case "$1" in
-d) arp -d $GW_ADDR;;
-s) ip neigh list;;
-b) arp -s $GW_ADDR $GW_HW_ADDR;;
-t) ping $GW_ADDR;;
*) break;;
esac
shift
done
exit 0
使用起来 #arputil -dbt 方便不少；
Javier say:great explaination for me!First things first, Snort is an Intrusion Detection System, so it's more targeted towards finding attacks in the network targeted against internal systems. However, Snort does provide rules for common virus signatures (transmitted through e-mail, by inspecting the SMTP traffic) and worms (by detecting their activity on the network). Notice, however, that if you want to detect new worms you should not rely on the Snort rules provided in the current stable release, as they are quite out of date. You can download updated rules from snort.org. You might want to update it too using a backported package of a newer version than the one in stable [1]
A separate method for detecting worms in your network is to prove the systems you manage using a vulnerability assesment tool. You can use Nessus for that (provided in Debian). Again, make sure that you use an updated version (not the one from stable, backports are available [2])
Nessus provides some plugins to test for installed backdoors, trojans and known worms. However, a Nessus scan is quite intrusive (it might even kill some systems) so you should approach that possibility with care. You can update your Nessus server with new attack plugins using 'nessus-update-plugins'
A third way to do what you propose (detect trojans, worms, etc.) is to do statistical analysis of the traffic generated by your clients and the amount of traffic (bandwith usage). That kind of analysis can enable to nail down some nasty clients. Sometimes you need to go down to the physical level (i.e. to the switches to obtain port statistics) since some worms might be doing TCP/IP spoofing (IIRC Slammer did this). In order to do statistical analysis it is usually good to keep up with Internet trends, something you can do visiting the "Internet Storm Center" [3]. Some traffic (like constant outgoing traffic to port 135 against random or consecutive IP addresses) is usually an indicative of a worm spreading. Again, tools to do this include ntop, iptraf, darkstat (for statistical analysis) and ethereal, tcpdump, sniff, ettercap, nwatch adn sniffit (amongst others)
Finally, since many of the virus nowadays are mass-mailing, it might be worth analysing the amount of outbound e-mail sent by internal clients. Even if you do not add an antivirus tool to your outgoing SMTP relay server (some av mail-server tools have already been commented on the replies you got) analysis of the amount of traffic might be sufficient to pin-point virus activity. There are a number of tools to generate that data, based on what you use as input (firewall logs, mail server logs...)
Hmmm... I've rambled for enough time... Happy hunting! :-)
Javier
[1] The maintainer provided backports for 2.0.1-3 which are available at http://people.debian.org/~ssmeenk/snort-stable-i386/ (I've tested those). I also made a backport (2.0.6-1) which I have testd also and can be retrieved from http://people.debian.org/~jfs/snort/ Finally, you can find packages for 2.1.0 (I don't have experience on these) at http://www.backports.org/debian/dists/stable/snort/binary-i386/
[2] Official backports available at http://people.debian.org/~jfs/nessus
[3] http://isc.incidents.org/