#
问题解决，解决方法如下：以secureCRT为例，菜单：选项-->会话选项...-->(类别)终端->外观-->字符编码，选择UTF-8，然后确定。。。
安装和设置 OpenSSH Server： sudo apt-get install openssh-server
然后确认sshserver是否启动了： ps -e |grep ssh
如果看到sshd那说明ssh-server已经启动了。
如果没有则可以这样启动： sudo /etc/init.d/ssh start
ssh-server配置文件位于/ etc/ssh/sshd_config
在这里可以定义SSH的服务端口，默认端口是22，你可以自己定义成其他端口号，如222。
然后重启SSH服务：
sudo /etc/init.d/ssh stop
sudo /etc/init.d/ssh start
然后通过Xshell等软件连接。Name为新建连接的名称，选择协议类型（Protocol）为“SSH”，Host为服务器的IP地址，端口（Port Number）为SSH协议的连接端口（默认为22），其他选项按照默认设置。
我在ubuntu12.04系统实际操作中执行了sudo apt-get install openssh-server之后按照提示安装成功。之后直接ssh localhost成功，然后外部机器就可以直接ssh过来了
1.启动Rad Hat 9.0(图形界面方式登陆)，并且以管理员的身份登陆。不用管理员身份不能安装。2.在VMware虚拟机的菜单中点击：虚拟机->安装VMware 工具->install。3.Red Hat 9.0自动挂载VMware Tools的虚拟光驱,并显示在桌面。4.进去VMware Tools的虚拟光驱里，把VMwareTools-5.5.1-19175.tar.gz复制到/tmp目录。5.进去/tmp目录，把VMwareTools-5.5.1-19175.tar.gz解压到当前目录下的一个文件夹中（VMwareTools-5文件夹）。6.同时按住Ctrl+Alt+F1三个键，进入字符界面，并以root身份登陆。7.输入以下命令：cp /tmp/VMwareTools-5/vmware-tools-distrib（进入vmware-tools-distrib目录）。8.输入：./vmware-install.pl（执行vmware-install.pl文件）。9.然后一路“回车”，能yes的就yes，就OK。10. 输入reboot命令(重新启动)。11.大功告成。
安装完Ubuntu后忽然意识到没有设置root密码，不知道密码自然就无法进入根用户下。到网上搜了一下，原来是这麽回事。Ubuntu的默认root密码是随机的，即每次开机都有一个新的root密码。我们可以在终端输入命令 sudo passwd，然后输入当前用户的密码，enter，终端会提示我们输入新的密码并确认，此时的密码就是root新密码。修改成功后，输入命令 su root，再输入新的密码就ok了。
摘要: 博客分类： 开发安全框架Shiro 授权即访问控制，它将判断用户在应用程序中对资源是否拥有相应的访问权限。 如，判断一个用户有查看页面的权限，编辑数据的权限，拥有某一按钮的权限，以及是否拥有打印的权限等等。 一、授权的三要素 授权有着三个核心元素：权限、角色和用户。 权限 权限是Apache Shiro安全机制最核心的元素。它在...
阅读全文
mysql-bin文件是数据库的操作日志，例如UPDATE一个表，或者DELETE一些数据，即使该语句没有匹配的数据，这个命令也会存储到日志文件中，还包括每个语句执行的时间，也会记录进去的。
这样做主要有以下两个目的：1：数据恢复：如果你的数据库出问题了，而你之前有过备份，那么可以看日志文件，找出是哪个命令导致你的数据库出问题了，想办法挽回损失。2：主从服务器之间同步数据 主服务器上所有的操作都在记录日志中，从服务器可以根据该日志来进行，以确保两个同步。处理方法分两种情况：
1：只有一个mysql服务器，那么可以简单的注释掉这个选项就行了。
vi /etc/my.cnf把里面的log-bin这一行注释掉，重启mysql服务即可。
2：如果你的环境是主从服务器，那么就需要做以下操作了。
A：在每个从属服务器上，使用SHOW SLAVE STATUS来检查它正在读取哪个日志。
B：使用SHOW MASTER LOGS获得主服务器上的一系列日志。
C：在所有的从属服务器中判定最早的日志，这个是目标日志，如果所有的从属服务器是更新的，就是清单上的最后一个日志。
D：清理所有的日志，但是不包括目标日志，因为从服务器还要跟它同步。
清理日志方法为：
PURGE MASTER LOGS TO 'mysql-bin.010';
PURGE MASTER LOGS BEFORE '2008-12-19 21:00:00';
如果你确定从服务器已经同步过了，跟主服务器一样了，那么可以直接RESET MASTER将这些文件删除。
查看mysql关于mysql-bin的配置
show variables like '%max_binlog_size%'
max_binlog_size 1073741824 默认大小为1G
但是mysql-bin文件过多会占用大量的磁盘空间，所以要对日志文件进行清理，方法如下：
1、
禁止方法: vi /etc/my.cnf把里面的#log-bin=mysql-bin注释掉,重启mysql服务即可.2、mysql> reset master;或flush logs; (清除日志文件)3、mysql> set global expire_logs_days=2；只保留两天的mysql-bin日志4、删除ablelee.000003之前的而没有包含ablelee.000003
mysql> purge binary logs to 'ablelee.000003';
当磁盘大小超过标准时会有报警提示，这时如果掌握df和du命令是非常明智的选择。
df可以查看一级文件夹大小、使用比例、档案系统及其挂入点，但对文件却无能为力。
du可以查看文件及文件夹的大小。
两者配合使用，非常有效。比如用df查看哪个一级目录过大，然后用df查看文件夹或文件的大小，如此便可迅速确定症结。
下面分别简要介绍
df命令可以显示目前所有文件系统的可用空间及使用情形，请看下列这个例子：
以下是代码片段： [yayug@yayu ~]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 3.9G 300M 3.4G 8% /
/dev/sda7 100G 188M 95G 1% /data0
/dev/sdb1 133G 80G 47G 64% /data1
/dev/sda6 7.8G 218M 7.2G 3% /var
/dev/sda5 7.8G 166M 7.2G 3% /tmp
/dev/sda3 9.7G 2.5G 6.8G 27% /usr
tmpfs 2.0G 0 2.0G 0% /dev/shm |
参数 -h 表示使用「Human-readable」的输出，也就是在档案系统大小使用 GB、MB 等易读的格式。
上面的命令输出的第一个字段（Filesystem）及最后一个字段（Mounted on）分别是档案系统及其挂入点。我们可以看到 /dev/sda1 这个分割区被挂在根目录下。
接下来的四个字段 Size、Used、Avail、及 Use% 分别是该分割区的容量、已使用的大小、剩下的大小、及使用的百分比。 FreeBSD下，当硬盘容量已满时，您可能会看到已使用的百分比超过 100%，因为 FreeBSD 会留一些空间给 root，让 root 在档案系统满时，还是可以写东西到该档案系统中，以进行管理。
du：查询文件或文件夹的磁盘使用空间
如果当前目录下文件和文件夹很多，使用不带参数du的命令，可以循环列出所有文件和文件夹所使用的空间。这对查看究竟是那个地方过大是不利的，所以得指定深入目录的层数，参数：--max-depth=，这是个极为有用的参数！如下，注意使用“*”，可以得到文件的使用空间大小.
提醒：一向命令比linux复杂的FreeBSD，它的du命令指定深入目录的层数却是比linux简化，为 -d。
以下是代码片段： [root@bsso yayu]# du -h --max-depth=1 work/testing
27M work/testing/logs
35M work/testing [root@bsso yayu]# du -h --max-depth=1 work/testing/*
8.0K work/testing/func.php
27M work/testing/logs
8.1M work/testing/nohup.out
8.0K work/testing/testing_c.php
12K work/testing/testing_func_reg.php
8.0K work/testing/testing_get.php
8.0K work/testing/testing_g.php
8.0K work/testing/var.php [root@bsso yayu]# du -h --max-depth=1 work/testing/logs/
27M work/testing/logs/ [root@bsso yayu]# du -h --max-depth=1 work/testing/logs/*
24K work/testing/logs/errdate.log_show.log
8.0K work/testing/logs/pertime_show.log
27M work/testing/logs/show.log |
值得注意的是，看见一个针对du和df命令异同的文章：《du df 差异导致文件系统误报解决》。
du 统计文件大小相加
df 统计数据块使用情况
如果有一个进程在打开一个大文件的时候,这个大文件直接被rm 或者mv掉，则du会更新统计数值，df不会更新统计数值,还是认为空间没有释放。直到这个打开大文件的进程被Kill掉。
如此一来在定期删除 /var/spool/clientmqueue下面的文件时，如果没有杀掉其进程，那么空间一直没有释放。
使用下面的命令杀掉进程之后，系统恢复。
fuser -u /var/spool/clientmqueue
http://www.yayu.org/look.php?id=162
查看linux文件目录的大小和文件夹包含的文件数
统计总数大小
du -sh xmldb/
du -sm * | sort -n //统计当前目录大小 并安大小 排序
du -sk * | sort -n
du -sk * | grep guojf //看一个人的大小
du -m | cut -d "/" -f 2 //看第二个/ 字符前的文字
查看此文件夹有多少文件 /*/*/* 有多少文件
du xmldb/
du xmldb/*/*/* |wc -l
40752
解释：
wc [-lmw]
参数说明：
-l :多少行
-m:多少字符
-w:多少字
http://linux.chinaitlab.com/command/734706.html
Linux:ls以K、M、G为单位查看文件大小
#man ls
……
-h, --human-readable
print sizes in human readable format (e.g., 1K 234M 2G)
……
# ls
cuss.war nohup.out
# ls -l
total 30372
-rw-r--r-- 1 root root 31051909 May 24 10:07 cuss.war
-rw------- 1 root root 0 Mar 20 13:52 nohup.out
# ls -lh
total 30M
-rw-r--r-- 1 root root 30M May 24 10:07 cuss.war
-rw------- 1 root root 0 Mar 20 13:52 nohup.out
# ll -h
total 30M
-rw-r--r-- 1 root root 30M May 24 10:07 cuss.war
-rw------- 1 root root 0 Mar 20 13:52 nohup.out
碰到问题先别急，按下面的思路去套，先一步步地定位问题、细化问题。
千万别在论坛、群里问，我的机器好慢怎么回事？我的机器内存泄露了怎么回事？
这类大而空的问题一点意义都没有，其实谁都不知道。你要做的是用下面的思路、方法、工具去定位它
------------------------------
解决问题思路
Java程序问题（运行慢）
先通过 top 查看整个CPU资源使用情况；
通过top -Hp pid查看java进程的每一个线程占用CPU的情况；
如果有一个线程占用CPU过高，有两种可能：
没有内存了，Java垃圾回收线程不停地运行尝试回收内存，但是每次无法收回，确认：
jstat -gcutil pid 1s 观察10多秒钟就能发现了，看是不是内存使用率接近100%了
类似于死循环（hash冲突攻击），就是一个线程一直占用一个核的所有CPU资源（其实一个线程总是暂用一个核超过50%的资源都是不太正常的），解决：
用我课堂的checkPerf脚本，定位这个线程具体执行的任务（能具体到某一行），对应看代码解决。
如果有很多线程，每个线程占用的CPU都不多，那基本是正常的。
如果死锁：
jstack -l pid 多执行几次，统计一下stack中总是在等待哪些锁，可以对锁id进行排序统计（sort uniq grep）
上面列出来的都是明显的瓶颈，最可怕的是哪里都没有明显的瓶颈，哪里都要偷一点点资源走，这是可以试试JProfiler这样更专业一点的工具，同时要配合自己对业务的了解来解决。
Java内存的问题，如果有内存泄露（就是执行完fgc/old gc后不能回收的内存不断地增加）：
快速解决：jmap -histo:live pid 来统计所有对象的个数（String/char/Integer/HashEntry 这样的对象很多很正常，主要是盯着你们公司的包名下的那些对象）
每隔一分钟执行一次上面的命令，执行5次以上，看看你们公司报名下的对象数量哪个在一直增加，那基本上就是这个对象引起了泄露；
用课堂上的工具HouseMD来动态监控创建这个对象的地方（一般来说很多时候创建了这些对象把他们丢到一个HashMap然后就不管了），分析一下有没有释放！
上面的方法实在没法定位就用: jmap -dump 导出整个内存（耗时间，需要很大的内存的机器才能对这个导出文件进行分析，会将JVM锁住一段时间）
在Eclipse的插件EMA中打开这个文件（2G的物理文件需要4G以上的内存，5G以上的需要将近20G的内存来分析了）
盯着你们公司报名的那些对象，看看引用关系，谁拿着这些对象没释放（是否是必要的）
MySQL 数据库的性能问题
大部分情况下是磁盘IO的问题（索引没建好、查询太复杂）；
索引问题的话分析慢查询日志，explain 他们挨个解决。
偶尔也有数据库CPU不够的情况，如果并发高CPU不够很正常，如果并发不高，那很可能就是group by/order by/random之类的操作严重消耗了数据库的CPU
mysql -e "show full processlist" | grep -v Sleep | sort -rnk6 查看那些SQL语句执行的太长
拿出这个SQL语句分析他们的执行计划: explain SQL 然后改进；
分析慢查询日志，统计top10性能杀手的语句，挨个explain他们，然后改进（具体改进办法具体分析，这里只谈思路）
总结一下数据库问题就只有这三招：show full processlist/分析慢查询日志/explain（然后建好联合索引）
mysql：http:x//mirrors.sohu.com/mysql/MySQL-5.5/mysql-5.5.14.tar.gz
cmake：http://www.cmake.org/cmake/resources/software.html
首先要安装cmake
#tar zxf cmake-2.8.5.tar.gz
#cd cmake-2.8.5
#./bootstrap
#make
#make install
依据源码安装mysql
useradd mysql
tar zxf mysql-5.5.14.tar.g
cd mysql-5.5.14
CFLAGS="-O3" CXX=gcc
CXXFLAGS="-O3 -felide-constructors -fno-exceptions -fno-rtti"
cmake . -LH|more //CMake下查看MySQL的编译配置
/usr/local/bin/cmake -DCMAKE_INSTALL_PREFIX=/opt/mysql \
-DMYSQL_UNIX_ADDR=/opt/mysql/mysql.sock \
-DDEFAULT_CHARSET=utf8 \
-DDEFAULT_COLLATION=utf8_general_ci \
-DWITH_EXTRA_CHARSETS=all \
-DWITH_MYISAM_STORAGE_ENGINE=1 \
-DWITH_INNOBASE_STORAGE_ENGINE=1 \
-DWITH_READLINE=1 \
-DENABLED_LOCAL_INFILE=1 \
-DMYSQL_DATADIR=/opt/mysql/data \
-DMYSQL_TCP_PORT=3306 \
make; make install
cd /opt
chown -R mysql:mysql mysql
cd /opt/mysql
chmod 777 data
./scripts/mysql_install_db
./scripts/mysql_install_db --user=mysql --datadir=/opt/mysql/data
update mysql.user set password=PASSWORD('1234') where User='root';
flush privileges;
show variables like 'character_set_%'; 字符集查看
redhat需要装的库
yum -y install patch make gcc gcc-c++ gcc-g77 flex bison file
yum -y install libtool libtool-libs autoconf kernel-devel
yum -y install libjpeg libjpeg-devel libpng libpng-devel libpng10 libpng10-devel gd gd-devel
yum -y install freetype freetype-devel libxml2 libxml2-devel zlib zlib-devel
yum -y install glib2 glib2-devel bzip2 bzip2-devel libevent libevent-devel
yum -y install ncurses ncurses-devel curl curl-devel e2fsprogs
yum -y install e2fsprogs-devel krb5 krb5-devel libidn libidn-devel
yum -y install openssl openssl-devel vim-minimal nano sendmail
yum -y install fonts-chinese gettext gettext-devel
yum -y install ncurses-devel
yum -y install gmp-devel pspell-devel
yum -y install unzip
注意：如果忘记先安装库，在cmake的时候报错了，得先把库安装一遍，然后删除/opt/mysql-5.6.21/CMakeCache.txt重新cmake一遍就行了.
mysql刚刚装好root初始密码是空的，直接回车就行了
修改授权以便远程机器能够访问
在安装mysql的机器上运行：
1、d:\mysql\bin\>mysql -h localhost -u root //这样应该可以进入MySQL服务器
2、mysql>GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION //赋予任何主机访问数据的权限
3、mysql>FLUSH PRIVILEGES //修改生效
4、mysql>EXIT //退出MySQL服务器
众所周知，Spring的事务控制是基于AOP来实现的，一个声明了事务管理的方法（如某个Service的方法）在执行时会被拦截，拦截时执行的“附加”操作集中在：
org.springframework.transaction.interceptor.TransactionInterceptor.invoke(MethodInvocation)
作为一个环绕切面，该方法主要负责在目标方法执行前开始一个事务，在方法执行结束后提交事务。
我们先来深入了解一下事务是如何创建的。从方法createTransactionIfNecessary()上可以看到，创建事务的主要方法是：
org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(TransactionDefinition)
作为抽象类的方法，getTransaction()只处理了一些通用性的检查和设置，实质性的创建事务和开启事务操作都是通过分别调用抽象方法：
org.springframework.transaction.support.AbstractPlatformTransactionManager.doGetTransaction()
和
org.springframework.transaction.support.AbstractPlatformTransactionManager.doBegin(Object,TransactionDefinition)
来完成的，也就是说这些关键性的工作必须由各具体事务管理器来实现，对于hibernate的事务管理器来说，获取事务对象的方法如下：
开始事务的方法如下：
以上是关于事务开始部分的代码，下面我们来看一下事务提交时的代码：
同样的，从方法commitTransactionAfterReturning()我们可以看出执行事务提交的方法主要通过回调
org.springframework.orm.hibernate3.HibernateTransactionManager.doCommit(DefaultTransactionStatus)
来实现的。
补充：
关于方法
org.springframework.transaction.support.TransactionSynchronizationManager.getResource(Object key)
如该方法的注释所说，它主要是通过给定的key找到对应的资源，特别之处是这些资源实例是绑定在线程上的，也就是spring保证一个线程上一个key对应一个资源实例，不同的线程上绑定的是不同的资源实例。对应到Hibernate上来说，key是sessionFactory,资源是sessionHolder！
作者：bluishglc
转自：
http://www.2cto.com/kf/201207/142772.html