All posts by admin

  • 首页   /  
  • 作者： admin
    • ( 页面4 )

CentOS 6.5升级至CentOS 7完整步骤及注意事项

留下评论

一 背景：

1 公司内部大量开发、测试、UAT环境机器都是CentOS 6.5的物理机/虚拟机；
2 公司在阿里云上的ECS机器环境同样多数为CentOS 6.5;
3 近期，公司内部在推Docker技术，而相对稳定且版本不至于太低的docker，需要部署在至少RHEL/CentOS 7.0以上版本的操作系统上。

二 说明：

本文档用于记录升级Centos 6.5到CentOS 7.2版本的操作步骤，以及升级后带来的问题和解决办法。升级前，本机的OS版本、内核版本、文件系统信息如下：

[root@dev-middleware ~]# cat /etc/redhat-release 
CentOS release 6.5 (Final)
[root@dev-middleware ~]# uname -rm
2.6.32-431.el6.x86_64 x86_64
[root@dev-middleware ~]# df -Th
Filesystem                   Type   Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup-lv_root ext4    50G   40G  7.2G  85% /
tmpfs                        tmpfs  1.9G     0  1.9G   0% /dev/shm
/dev/sda1                    ext4   485M   32M  428M   7% /boot
/dev/mapper/VolGroup-lv_home ext4   144G  193M  136G   1% /home
[root@dev-middleware ~]#

根据从网络上的获取的相关参考信息，本文档中的内容和步骤并不适用于Centos其它版本6.X升级至CentOS 7的参考。且，该升级是in-place-upgrade的升级方式，即直接在原机上执行升级的操作，存在一定风险。而官方推荐的非in-place-upgrade的方式，即先备份相关的文件和数据，然后安装CentOS 7系统，再恢复还原相关数据的作法，相对比较安全可控。

三 升级：

1 添加1个yum的repo文件：

vi /etc/yum.repo.d/upgrade.repo
内容为：

[upg]
name=CentOS-$releasever - Upgrade Tool
baseurl=http://dev.centos.org/centos/6/upg/x86_64/
gpgcheck=1
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6

2 安装升级工具：

yum install redhat-upgrade-tool preupgrade-assistant-contents

3 执行预升级检查：

preupg -l

preupg -s CentOS6_7

如果有类似下述错误：

I/O warning : failed to load external entity "/usr/share/openscap/xsl/security-guide.xsl"
compilation error: file /usr/share/preupgrade/xsl/preup.xsl line 40 element import
xsl:import : unable to load /usr/share/openscap/xsl/security-guide.xsl
I/O warning : failed to load external entity "/usr/share/openscap/xsl/oval-report.xsl"
compilation error: file /usr/share/preupgrade/xsl/preup.xsl line 41 element import
xsl:import : unable to load /usr/share/openscap/xsl/oval-report.xsl
I/O warning : failed to load external entity "/usr/share/openscap/xsl/sce-report.xsl"
compilation error: file /usr/share/preupgrade/xsl/preup.xsl line 42 element import
xsl:import : unable to load /usr/share/openscap/xsl/sce-report.xsl
OpenSCAP Error:: Could not parse XSLT file '/usr/share/preupgrade/xsl/preup.xsl' [oscapxml.c:416]
Unable to open file /root/preupgrade/result.html
Usage: preupg [options]
preupg: error: [Errno 2] No such file or directory: '/root/preupgrade/result.html'

则，原因是openscap软件包的版本太高。通过下述先删除，再安装的来办法解决：

yum erase openscap
yum install http://dev.centos.org/centos/6/upg/x86_64/Packages/openscap-1.0.8-1.0.1.el6.centos.x86_64.rpm
yum install redhat-upgrade-tool preupgrade-assistant-contents

4 再次执行，预升级检查：

preupg -s CentOS6_7

执行结果：

....
094/096 ...done (NIS server maps check)
095/096 ...done (NIS server MAXUID and MAXGID limits check)
096/096 ...done (NIS server config file back-up)
Assessment finished (time 02:15s)
Result table with checks and their results for main contents:
....

|Content for enabling and disabling services based on CentOS 6 system |needs_action |
---------------------------------------------------------------------------------------------------------------
Tarball with results is stored here /root/preupgrade-results/preupg_results-170510111635.tar.gz .
The latest assessment is stored in directory /root/preupgrade .
Summary information:
We found some potential in-place upgrade risks.
Read the file /root/preupgrade/result.html for more details.
Upload results to UI by command:
e.g. preupg -u http://127.0.0.1:8099/submit/ -r /root/preupgrade-results/preupg_results-*.tar.gz .

执行升级的过程中，可能会有的一些不兼容问题，则都在上述的预升级检查结果中，需要关注并处理。

5 导入仓库的RPM签名证书

 rpm --import http://172.16.11.36/yum/test/RPM-GPG-KEY-CentOS-7

需要说明的是，这里导入的是使用本地搭建的一个yum源的签名证书。这个本地源，是基于从网络上下载的CentOS-7-x86_64-DVD-1611.iso进行搭建的。当然，并不一定非要搭建本地yum源，也可以直接从下载的该ISO文件中，获取RPM-GPG-KEY-CentOS-7，直接在本地机器执行导入。为什么这么做，后面会有详细的解释和说明。
该文件的内容如下：

[root@localhost test]# cat RPM-GPG-KEY-CentOS-7
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.5 (GNU/Linux)

mQINBFOn/0sBEADLDyZ+DQHkcTHDQSE0a0B2iYAEXwpPvs67cJ4tmhe/iMOyVMh9
Yw/vBIF8scm6T/vPN5fopsKiW9UsAhGKg0epC6y5ed+NAUHTEa6pSOdo7CyFDwtn
4HF61Esyb4gzPT6QiSr0zvdTtgYBRZjAEPFVu3Dio0oZ5UQZ7fzdZfeixMQ8VMTQ
4y4x5vik9B+cqmGiq9AW71ixlDYVWasgR093fXiD9NLT4DTtK+KLGYNjJ8eMRqfZ
Ws7g7C+9aEGHfsGZ/SxLOumx/GfiTloal0dnq8TC7XQ/JuNdB9qjoXzRF+faDUsj
WuvNSQEqUXW1dzJjBvroEvgTdfCJfRpIgOrc256qvDMp1SxchMFltPlo5mbSMKu1
x1p4UkAzx543meMlRXOgx2/hnBm6H6L0FsSyDS6P224yF+30eeODD4Ju4BCyQ0jO
IpUxmUnApo/m0eRelI6TRl7jK6aGqSYUNhFBuFxSPKgKYBpFhVzRM63Jsvib82rY
438q3sIOUdxZY6pvMOWRkdUVoz7WBExTdx5NtGX4kdW5QtcQHM+2kht6sBnJsvcB
JYcYIwAUeA5vdRfwLKuZn6SgAUKdgeOtuf+cPR3/E68LZr784SlokiHLtQkfk98j
NXm6fJjXwJvwiM2IiFyg8aUwEEDX5U+QOCA0wYrgUQ/h8iathvBJKSc9jQARAQAB
tEJDZW50T1MtNyBLZXkgKENlbnRPUyA3IE9mZmljaWFsIFNpZ25pbmcgS2V5KSA8
c2VjdXJpdHlAY2VudG9zLm9yZz6JAjUEEwECAB8FAlOn/0sCGwMGCwkIBwMCBBUC
CAMDFgIBAh4BAheAAAoJECTGqKf0qA61TN0P/2730Th8cM+d1pEON7n0F1YiyxqG
QzwpC2Fhr2UIsXpi/lWTXIG6AlRvrajjFhw9HktYjlF4oMG032SnI0XPdmrN29lL
F+ee1ANdyvtkw4mMu2yQweVxU7Ku4oATPBvWRv+6pCQPTOMe5xPG0ZPjPGNiJ0xw
4Ns+f5Q6Gqm927oHXpylUQEmuHKsCp3dK/kZaxJOXsmq6syY1gbrLj2Anq0iWWP4
Tq8WMktUrTcc+zQ2pFR7ovEihK0Rvhmk6/N4+4JwAGijfhejxwNX8T6PCuYs5Jiv
hQvsI9FdIIlTP4XhFZ4N9ndnEwA4AH7tNBsmB3HEbLqUSmu2Rr8hGiT2Plc4Y9AO
aliW1kOMsZFYrX39krfRk2n2NXvieQJ/lw318gSGR67uckkz2ZekbCEpj/0mnHWD
3R6V7m95R6UYqjcw++Q5CtZ2tzmxomZTf42IGIKBbSVmIS75WY+cBULUx3PcZYHD
ZqAbB0Dl4MbdEH61kOI8EbN/TLl1i077r+9LXR1mOnlC3GLD03+XfY8eEBQf7137
YSMiW5r/5xwQk7xEcKlbZdmUJp3ZDTQBXT06vavvp3jlkqqH9QOE8ViZZ6aKQLqv
pL+4bs52jzuGwTMT7gOR5MzD+vT0fVS7Xm8MjOxvZgbHsAgzyFGlI1ggUQmU7lu3
uPNL0eRx4S1G4Jn5
=OGYX
-----END PGP PUBLIC KEY BLOCK-----
[root@localhost test]#

6 执行升级：

 
centos-upgrade-tool-cli --network 7 --instrepo=http://vault.centos.org/centos/7.2.1511/os/x86_64/
setting up repos...
.treeinfo | 1.1 kB 00:00
Preupgrade assistant risk check found risks for this upgrade.
You can run preupg --riskcheck --verbose to view these risks.
Addressing high risk issues is required before the in-place upgrade
and ignoring these risks may result in a broken upgrade and unsupported upgrade.
Please backup your data.
...
...

(276/277): zlib-1.2.7-17.el7.x86_64.rpm | 90 kB 00:00
(277/277): zlib-devel-1.2.7-17.el7.x86_64.rpm | 50 kB 00:00
testing upgrade transaction
rpm transaction 100% [======================================================================================================================================================]
rpm install 100% [==========================================================================================================================================================]
setting up system for upgrade
Finished. Reboot to start upgrade.

7 根据提示，重启升级。

升级后的OS、内核版本、文件系统信息如下：

[root@dev-middleware conf.d]# cat /etc/redhat-release
CentOS Linux release 7.2.1511 (Core)
[root@dev-middleware conf.d]# uname -rm
3.10.0-327.el7.x86_64 x86_64
[root@dev-middleware conf.d]# df -Th
文件系统 类型 容量 已用 可用 已用% 挂载点
/dev/mapper/VolGroup-lv_root ext4 50G 43G 4.3G 91% /
devtmpfs devtmpfs 1.9G 0 1.9G 0% /dev
tmpfs tmpfs 1.9G 0 1.9G 0% /dev/shm
tmpfs tmpfs 1.9G 80M 1.8G 5% /run
tmpfs tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup
/dev/sda1 ext4 477M 110M 338M 25% /boot
/dev/mapper/VolGroup-lv_home ext4 144G 354M 136G 1% /home
[root@dev-middleware conf.d]#

四 遇到的问题，及解决办法

1 Downloading failed: invalid data in .treeinfo: No option ‘upgrade’ in section: ‘images-x86_64’
升级过程中，可能会遇到：No option ‘upgrade’ in section: ‘images-x86_64’：

redhat-upgrade-tool --network 7.0 --force --instrepo  http://mirrors.aliyun.com/centos/7.3.1611/os/x86_64/
setting up repos...
YumRepo Error: All mirror URLs are not using ftp, http[s] or file.
 Eg. Invalid release/
removing mirrorlist with no valid mirrors: /var/tmp/system-upgrade/base/mirrorlist.txt
YumRepo Error: All mirror URLs are not using ftp, http[s] or file.
 Eg. Invalid release/
removing mirrorlist with no valid mirrors: /var/tmp/system-upgrade/extras/mirrorlist.txt
YumRepo Error: All mirror URLs are not using ftp, http[s] or file.
 Eg. Invalid release/
removing mirrorlist with no valid mirrors: /var/tmp/system-upgrade/updates/mirrorlist.txt
No upgrade available for the following repos: base extras updates
.treeinfo                                                                                                                                             |  946 B     00:00     
getting boot images...

Downloading failed: invalid data in .treeinfo: No option 'upgrade' in section: 'images-x86_64'

原因，如果使用互联上的签名文件的话，互联网上的yum源都会有相同的报错，.treeinfo: No option ‘upgrade’ in section: ‘images-x86_64’。即，网上的yum源下的文件.treeinfo里都没有upgrade选项。所以，经过测试，才使用了上述升级步骤中的导入本地rpm签名证书。

2 升级后，遇到nginx启动报错，Starting nginx: /usr/sbin/nginx: error while loading shared libraries: libpcre.so.0: cannot open shared object file: No such file or directory

[root@dev-middleware ~]# systemctl status nginx.service
● nginx.service - LSB: start and stop nginx
Loaded: loaded (/etc/rc.d/init.d/nginx; bad; vendor preset: disabled)
Active: failed (Result: exit-code) since 六 2017-05-27 16:49:28 CST; 5min ago
Docs: man:systemd-sysv-generator(8)

5月 27 16:49:28 dev-middleware systemd[1]: Starting LSB: start and stop nginx...
5月 27 16:49:28 dev-middleware nginx[1661]: Starting nginx: /usr/sbin/nginx: error while loading shared libraries: libpcre.so.0: cannot open shared object file: No such file or directory
5月 27 16:49:28 dev-middleware nginx[1661]: [失败]
5月 27 16:49:28 dev-middleware systemd[1]: nginx.service: control process exited, code=exited status=1
5月 27 16:49:28 dev-middleware systemd[1]: Failed to start LSB: start and stop nginx.
5月 27 16:49:28 dev-middleware systemd[1]: Unit nginx.service entered failed state.
5月 27 16:49:28 dev-middleware systemd[1]: nginx.service failed.
[root@dev-middleware ~]#

解决办法：

a 查找libpcre.so文件
 
[root@dev-middleware ~]# find / -name libpcre.so*
/usr/lib64/libpcre.so.1.2.0
/usr/lib64/libpcre.so
/usr/lib64/libpcre.so.1
/usr/lib64/libpcre.so.0
[root@dev-middleware ~]#
b 创建链接文件
 
[root@dev-middleware ~]# link /usr/lib64/libpcre.so.1 /lib64/libpcre.so.0
c 输出LD_LIBRARY_PATH环境变量
 
[root@dev-middleware ~]# export LD_LIBRARY_PATH=/usr/local/lib:/lib64:$LD_LIBRARY_PATH
[root@dev-middleware ~]# echo $LD_LIBRARY_PATH
/usr/local/lib:/lib64:/usr/lib64:/usr/local/lib:
[root@dev-middleware ~]#
d 相关链接：

链接：
关于共享库找不到：
http://sempike.blogspot.com/2016/02/update-to-centos-7-libpcreso0-no-such.html
关于nginx启动报错：
http://blog.csdn.net/bzhxuexi/article/details/35821121
为防止以后出错，还是把export LD_LIBRARY_PATH=/usr/local/lib:/lib64:$LD_LIBRARY_PATH写入root的profile。

3 升级后，遇到类似问题：/ppas/9.3as/bin/edb-postgres: error while loading shared libraries: libsasl2.so.2: cannot open shared object file: No such file or directory

这是，之前一台运行CentOS 6.5的机器，上面跑着PostgreSQL数据库，升级到CentOS 7版本之后，数据库启动失败。

[enterprisedb@localhost ~]$ pg_ctl start
/ppas/9.3as/bin/edb-postgres: error while loading shared libraries: libsasl2.so.2: cannot open shared object file: No such file or directory
no data was returned by command ""/ppas/9.3as/bin/edb-postgres" -V"
The program "edb-postgres" is needed by pg_ctl but was not found in the
same directory as "/ppas/9.3as/bin/pg_ctl".
Check your installation.
[enterprisedb@localhost ~]$

解决办法：

a root创建链接文件：
 
[root@localhost ~]# find / -name libsasl2.*
/usr/lib64/libsasl2.so.3.0.0
/usr/lib64/libsasl2.so.3
[root@localhost ~]# link /usr/lib64/libsasl2.so.3 /lib64/libsasl2.so.2
b 然后，PostgreSQL数据库用户，输出环境变量：
 
[enterprisedb@localhost ~]$ export LD_LIBRARY_PATH=/usr/lib64/:/lib64
[enterprisedb@localhost ~]$ echo $LD_LIBRARY_PATH
/usr/lib64/:/lib64
[enterprisedb@localhost ~]$ pg_ctl status
pg_ctl: no server running
[enterprisedb@localhost ~]$ pg_ctl start
server starting
[enterprisedb@localhost ~]$ 2017-05-27 17:18:05 CST 日志:

** EnterpriseDB Dynamic Tuning Agent ********************************************
* System Utilization: 100% *
* Database Version: 9.3.11.33 *
* Operating System Version: *
* Number of Processors: 0 *
* Processor Type: *
* Processor Architecture: *
* Database Size: 0.1 GB *
* RAM: 15.5 GB *
* Shared Memory: 15839 MB *
* Max DB Connections: 0 *
* Autovacuum: on *
* Autovacuum Naptime: 60 Seconds *
* InfiniteCache: off *
* InfiniteCache Servers: 0 *
* InfiniteCache Size: 0.000 GB *
*********************************************************************************

2017-05-27 17:18:05 CST 日志: 已加载的库 "$libdir/dbms_pipe"
2017-05-27 17:18:05 CST 日志: 已加载的库 "$libdir/edb_gen"
2017-05-27 17:18:05 CST 日志: redirecting log output to logging collector process
2017-05-27 17:18:05 CST 提示: Future log output will appear in directory "pg_log".

[enterprisedb@localhost ~]$

五 参考链接:

远程升级云服务器系统 CentOS 6.x 至 CentOS 7.x

PostgreSQL授予/回收其他用户访问当前用户下所有表的权限小结

留下评论

Q1:PostgreSQL数据库中，如何授予其他用户可以查询当前用户下的所有表的权限？

A1:分2个步骤。首先，赋予其他用户访问当前用户下所有表的查询权限；其次，其他用户要有使用当前用户的schema的权限。

例子：当前库为testdb，当前用户为testu1,schema为test_schema,表为t1,t2。如何让其他用户testu2有查询t1、t2表的权限？

当前数据库版本为EDB 9.3,以testu1连接到testdb数据库，在test_schema下有2张表,t1和t2,各有1条记录。

testdb=> select version;
                                                       version                                                       
---------------------------------------------------------------------------------------------------------------------
 EnterpriseDB 9.3.11.33 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-55), 64-bit
(1 row)

testdb=> \c
You are now connected to database "testdb" as user "testu1".
testdb=> \dn
      List of schemas
    Name     |    Owner     
-------------+--------------
 public      | enterprisedb
 test_schema | testu1
(2 rows)

testdb=> \d            
          List of relations
   Schema    | Name | Type  | Owner  
-------------+------+-------+--------
 test_schema | t1   | table | testu1
 test_schema | t2   | table | testu1
(2 rows)

testdb=> select * from t1;
 id 
----
  1
(1 row)

testdb=> select * from t2;
 id 
----
  2
(1 row)

testdb=>

同时，testu2用户连接testdb时，不能访问testu1在test_schema下的表。提示，对模式 test_schema 权限不够。

testdb=> \c
You are now connected to database "testdb" as user "testu2".
testdb=> \dn
      List of schemas
    Name     |    Owner     
-------------+--------------
 public      | enterprisedb
 test_schema | testu1
(2 rows)

testdb=> select * from test_schema.t1;
错误:  对模式 test_schema 权限不够
LINE 1: select * from test_schema.t1;
                      ^
testdb=>

接下来，testu1用户授权给testu2使用test_schema的权限。

testdb=> \c
You are now connected to database "testdb" as user "testu1".
testdb=> grant USAGE on SCHEMA test_schema to testu2;
GRANT
testdb=>

授权之后，看看testu2能否访问testu1在test_schema下的表？

 
postgres=# \c testdb testu2;
You are now connected to database "testdb" as user "testu2".
testdb=> select * from test_schema.t1;
错误:  对关系 t1 权限不够
testdb=>

不再提示对模式 test_schema 权限不够，而是对表的查询权限不够。
接下来，授予testu2对于test_schema下所有表的查询权限：

 
testdb=> \c
You are now connected to database "testdb" as user "testu1".
testdb=> grant SELECT on all tables in schema test_schema to testu2;
GRANT
testdb=>

最后，以testu2用户登录testdb数据库时，可以顺利访问testu1用户在test_schema下的所有表了：

testdb=> \c
You are now connected to database "testdb" as user "testu2".
testdb=> select * from test_schema.t1;
 id 
----
  1
(1 row)

testdb=> select * from test_schema.t2;
 id 
----
  2
(1 row)

testdb=>

Q2:对于已经授予某个用户查询当前用户下的指定schema下所有表的情况下，当前用户下在指定schema下创建的新表，其他用户是否有权限访问？如果没有，该怎么赋予其他用户查询当前用户新建的表？

A2:对于新建的表，其他用户没有查询权限。可以通过alter default privileges来赋予访问新建的表的权限。具体如下：

testu2用户在testdb数据库下的test_schema下新建t3表，testu2自己正常访问没问题。而testu2连接testdb数据库，则不能查询新建的t3表。

testdb=> \c
You are now connected to database "testdb" as user "testu1".
testdb=> create table t3(id int);
CREATE TABLE
testdb=> insert into t3 values(3);
INSERT 0 1
testdb=> select * from t3;
 id 
----
  3
(1 row)

testdb=> \c testdb testu2
You are now connected to database "testdb" as user "testu2".
testdb=> select * from test_schema.t3;
错误:  对关系 t3 权限不够
testdb=>

可以通过下述2种方法中的任意一种，来使testu2用户可以查询test1用户新建的t3表：

方法1

 testdb=> \c testdb testu1
You are now connected to database "testdb" as user "testu1".
testdb=> grant SELECT on all tables in schema test_schema to testu2;
GRANT
testdb=> \c testdb testu2
You are now connected to database "testdb" as user "testu2".
testdb=> select * from test_schema.t3;                              
 id 
----
  3
(1 row)

testdb=>

或者，方法2：

 
testdb=> \c testdb testu1
You are now connected to database "testdb" as user "testu1".
testdb=> revoke SELECT on t3 from testu2;
REVOKE
testdb=> \c testdb testu2
You are now connected to database "testdb" as user "testu2".
testdb=> select * from test_schema.t3;                  
错误:  对关系 t3 权限不够
testdb=> \c testdb testu1
You are now connected to database "testdb" as user "testu1".
testdb=> grant SELECT on t3 to testu2;
GRANT
testdb=> \c testdb testu2
You are now connected to database "testdb" as user "testu2".
testdb=> select * from test_schema.t3;  
 id 
----
  3
(1 row)

testdb=>

显然，上述的2种方法都不是最好的方法。不可能对于每一张新建的表都重新执行一次赋权操作。通过alter default privileges赋权操作来实现。

 
testdb=> \c testdb testu1
You are now connected to database "testdb" as user "testu1".
testdb=> alter default privileges in schema test_schema grant SELECT on tables to testu2;
ALTER DEFAULT PRIVILEGES
testdb=> create table t4(id int);
CREATE TABLE
testdb=> insert into t4 values(4);
INSERT 0 1
testdb=> select * from t4;
 id 
----
  4
(1 row)

testdb=> \c testdb testu2
You are now connected to database "testdb" as user "testu2".
testdb=> select * from test_schema.t4;                                                   
 id 
----
  4
(1 row)

testdb=>

此外，可以通过\ddp命令来查看默认权限[\describe default privileges,我猜测这条命令的简写意义所在]：

testdb=> \ddp+
            Default access privileges
 Owner  |   Schema    | Type  | Access privileges 
--------+-------------+-------+-------------------
 testu1 | test_schema | table | testu2=r/testu1
(1 row)

testdb=>

Q3:对于已经拥有默认权限的用户的情况下，如何删除？即，如何处理类似DETAIL: privileges for default privileges on new relations belonging to role testu1 in schema test_schema的错误？

A3：需要3个步骤。1，回收schema的usage权限；2，回收对所有表的查询权限；3，执行类似alter default privileges来回收默认权限后再删除。

即使通过最高权限的数据库管理员来删除testu2用户也报错，甚至加上cascade也删除不成功。

postgres=# \c
You are now connected to database "postgres" as user "enterprisedb".
postgres=# drop user testu2;
错误:  无法删除"testu2"因为有其它对象倚赖它
DETAIL:  在数据库 testdb中的6个对象
postgres=# drop user testu2 cascade;
错误:  无法删除"testu2"因为有其它对象倚赖它
DETAIL:  在数据库 testdb中的6个对象
postgres=#

依次回收schema的usage权限、回收所有表的查询权限、最后通过alter default privileges来回收默认权限,同时通过\ddp查看的默认权限为空：

testdb=> \c
You are now connected to database "testdb" as user "testu1".
testdb=> revoke USAGE on SCHEMA test_schema from testu2;
REVOKE
testdb=> revoke SELECT on all tables in schema test_schema from testu2;
REVOKE
testdb=> alter default privileges in schema test_schema revoke SELECT on tables from testu2;
ALTER DEFAULT PRIVILEGES
testdb=> \ddp
         Default access privileges
 Owner | Schema | Type | Access privileges 
-------+--------+------+-------------------
(0 rows)

testdb=>

最后，通过管理员来顺利删除testu2用户：

postgres=# drop user testu2;
DROP ROLE
postgres=#

小结：
1 把当前用户下某个schema下的表的查询权限赋给其他用户，既需要把schema的usage权限给其他用户，也要赋予其他用户对于表的查询权限（可以指定特定表来赋权查询操作，也可以赋予一次性赋予所有表的查询权限）；
2 对于将来新建表的查询权限想要一次性的赋予权限，则需要通过alter default privileges赋予默认权限来操作；
3 回收权限的话，需要回收schema的usage权限，也要回收表的查询权限，还有回收默认权限；
4 可以通过\ddp来查看默认赋权信息。

Java学习笔记002：primitive type效率高

留下评论

问题：在Java中，为什么使用primitive type的效率要比通过new来创建数据类型的效率高？

首先，在Java中，primitive type从字面上可以理解为基本数据类型，或者原始数据类型。它是char、byte、short、int、long、double、float、Boolean的统称。

其次，在Java中，存放数据的地方有下面5个地方。

  1. register,寄存器。即，位于CPU芯片上的寄存器，其特点是速度特别快，但是不能直接操作；
  2. stack,内存栈区。位于Random Access Memory上，即内存中。运行速度次于register，可直接操作；
  3. heap,内存堆。同样位于内存区。其特点是，所有通过new关键字来创建出来的对象都位于该内存堆区；
  4. Read Only Memory，只读存取器。通常用于存放常量或者静态的不变的数据；
  5. non-RAM,非内存存储。说白了，就是把那些可以独立于程序存放的数据，不放在上面任何一个地方存储。而是存放在诸如磁盘或光盘上。类似于Oracle数据库的外部表的数据不存放在数据库里，而是存放在数据库之外的存储上一样。

这里，有一个重点是，在Java中，所有通过new来创建的对象，都会存放在内存的heap区中。另外，从1-5的存储区，其运行速度是逐步降低的。因此，当我们使用new去创建对象/变量时，其运行速度肯定不如内存的stack区效率高。

所以，Java也沿袭了C/C++的做法，提供了一些原始数据类型，并且把这些类型的变量放到内存的stack区来处理。当我们需要使用这些类型的变量时，直接拿过来用即可，而不再需要通过new关键字来新建1个出来。如下，整型变量n1要比n2快：

 
public class PrimitiveType {
	public static void main(String[] args) {
		int n1 = 47;
		Integer n2 = new Integer(47);
		System.out.println("Fast:n1" + n1);
		System.out.println("Slow:n2" + n2);
	}
}

 

小结：Java中提供的原始数据类型，都是在内存的stack区处理。通过new来创建的变量是在内存的heap区进行处理。 前者执行效率要比通过new在内存heap区创建变量的执行效率高。

解决PostgreSQL因日志文件过少导致的故障

留下评论

1早上，公司一项目(近期在做一个活动，截止日期是今天，2017.4.9，估计有很大用户在截止日期之前，大量的刷票)同事反馈说，系统特别卡，极其的慢，页面刷不出来。

 

登录到数据库之后，看到大量的查询等待：

[root@ecs-yqb4 ~]# ps -ef|grep post
postgres 8939 1 0 2016 ? 00:02:33 /data/postgres/9.4.4/bin/postgres
postgres 8947 8939 0 2016 ? 00:02:23 postgres: checkpointer process
postgres 8948 8939 0 2016 ? 00:08:17 postgres: writer process
postgres 8949 8939 0 2016 ? 00:03:51 postgres: wal writer process
postgres 8950 8939 0 2016 ? 00:03:04 postgres: autovacuum launcher process
postgres 8951 8939 0 2016 ? 00:11:38 postgres: stats collector process
postgres 24561 8939 3 09:05 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54151) SELECT
postgres 24562 8939 3 09:05 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54152) SELECT
postgres 24563 8939 3 09:05 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54153) SELECT
postgres 24564 8939 3 09:05 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54154) SELECT
postgres 24565 8939 3 09:05 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54155) SELECT
postgres 24566 8939 3 09:05 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54156) SELECT
postgres 24567 8939 3 09:05 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54157) SELECT
postgres 24568 8939 3 09:05 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54158) SELECT
postgres 24569 8939 3 09:05 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54159) SELECT
postgres 24570 8939 3 09:05 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54160) SELECT
postgres 24748 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54210) SELECT
postgres 24749 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54211) SELECT
postgres 24750 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54212) SELECT
postgres 24751 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54213) SELECT
postgres 24752 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54214) SELECT
postgres 24753 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54215) SELECT
postgres 24754 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54216) SELECT
postgres 24755 8939 3 09:06 ? 00:01:19 postgres: onlyou_activity onlyou_activity 10.20.1.12(54217) SELECT
postgres 24756 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54218) SELECT
postgres 24757 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54219) SELECT
postgres 24758 8939 3 09:06 ? 00:01:19 postgres: onlyou_activity onlyou_activity 10.20.1.12(54220) SELECT
postgres 24759 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54221) SELECT
postgres 24760 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54222) SELECT
postgres 24761 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54223) SELECT
postgres 24762 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54224) SELECT
postgres 24763 8939 3 09:06 ? 00:01:19 postgres: onlyou_activity onlyou_activity 10.20.1.12(54225) SELECT
postgres 24764 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54226) SELECT
postgres 24765 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54227) SELECT
postgres 24766 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54228) SELECT
postgres 24767 8939 3 09:06 ? 00:01:19 postgres: onlyou_activity onlyou_activity 10.20.1.12(54229) SELECT
postgres 24768 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54230) SELECT
postgres 24769 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54231) SELECT
postgres 24770 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54232) SELECT
postgres 24771 8939 3 09:06 ? 00:01:19 postgres: onlyou_activity onlyou_activity 10.20.1.12(54233) idle in transaction
postgres 24773 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54234) SELECT
postgres 24774 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54235) SELECT
postgres 24775 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54236) SELECT
postgres 24776 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54237) SELECT
postgres 24778 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54238) SELECT
postgres 24779 8939 3 09:06 ? 00:01:21 postgres: onlyou_activity onlyou_activity 10.20.1.12(54239) SELECT
postgres 24780 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54240) SELECT
postgres 24781 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54241) SELECT
postgres 24782 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54242) SELECT
postgres 24783 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54243) SELECT
postgres 24784 8939 3 09:06 ? 00:01:21 postgres: onlyou_activity onlyou_activity 10.20.1.12(54244) SELECT
postgres 24785 8939 3 09:06 ? 00:01:19 postgres: onlyou_activity onlyou_activity 10.20.1.12(54245) SELECT
postgres 24786 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54246) SELECT
postgres 24787 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54247) SELECT
postgres 24788 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54248) SELECT
postgres 24789 8939 3 09:06 ? 00:01:19 postgres: onlyou_activity onlyou_activity 10.20.1.12(54249) SELECT
postgres 24790 8939 3 09:06 ? 00:01:21 postgres: onlyou_activity onlyou_activity 10.20.1.12(54250) SELECT
postgres 24791 8939 3 09:06 ? 00:01:21 postgres: onlyou_activity onlyou_activity 10.20.1.12(54251) SELECT
postgres 24793 8939 3 09:06 ? 00:01:19 postgres: onlyou_activity onlyou_activity 10.20.1.12(54252) SELECT
postgres 24795 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54253) SELECT
postgres 24797 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54254) SELECT
postgres 24798 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54255) SELECT
postgres 24799 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54256) SELECT
postgres 24800 8939 3 09:06 ? 00:01:21 postgres: onlyou_activity onlyou_activity 10.20.1.12(54257) SELECT
postgres 24801 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54258) SELECT
postgres 24803 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54259) idle
postgres 24804 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54260) SELECT
postgres 24805 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54261) SELECT
postgres 24806 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54262) SELECT
postgres 24808 8939 3 09:06 ? 00:01:21 postgres: onlyou_activity onlyou_activity 10.20.1.12(54263) SELECT
postgres 24809 8939 3 09:06 ? 00:01:19 postgres: onlyou_activity onlyou_activity 10.20.1.12(54264) SELECT
postgres 24810 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54265) SELECT
postgres 24811 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54266) SELECT
postgres 24812 8939 3 09:06 ? 00:01:19 postgres: onlyou_activity onlyou_activity 10.20.1.12(54267) SELECT
postgres 24813 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54268) SELECT
postgres 24814 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54269) SELECT
postgres 24815 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54270) SELECT
postgres 24816 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54271) SELECT
postgres 24817 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54272) SELECT
postgres 24818 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54273) idle
postgres 24819 8939 3 09:06 ? 00:01:21 postgres: onlyou_activity onlyou_activity 10.20.1.12(54274) SELECT
postgres 24820 8939 3 09:06 ? 00:01:19 postgres: onlyou_activity onlyou_activity 10.20.1.12(54275) SELECT
postgres 24821 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54276) SELECT
postgres 24822 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54277) SELECT
postgres 24823 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54278) SELECT
postgres 24826 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54279) SELECT
postgres 24827 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54280) SELECT
postgres 24828 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54281) SELECT
postgres 24829 8939 3 09:06 ? 00:01:21 postgres: onlyou_activity onlyou_activity 10.20.1.12(54282) SELECT
postgres 24830 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54283) SELECT
postgres 24831 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54284) SELECT
postgres 24832 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54285) SELECT
postgres 24833 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54286) SELECT
postgres 24834 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54287) SELECT
postgres 24835 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54288) SELECT
postgres 24836 8939 3 09:06 ? 00:01:19 postgres: onlyou_activity onlyou_activity 10.20.1.12(54289) SELECT
postgres 24837 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54290) SELECT
postgres 24838 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54291) SELECT
postgres 24840 8939 3 09:06 ? 00:01:19 postgres: onlyou_activity onlyou_activity 10.20.1.12(54292) SELECT
postgres 24841 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54293) SELECT
postgres 24842 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54294) SELECT
postgres 24843 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54295) SELECT
postgres 24844 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54296) SELECT
postgres 24845 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54297) SELECT
postgres 24846 8939 3 09:06 ? 00:01:20 postgres: onlyou_activity onlyou_activity 10.20.1.12(54298) SELECT
postgres 24849 8939 3 09:06 ? 00:01:19 postgres: onlyou_activity onlyou_activity 10.20.1.12(54299) SELECT
root 25338 25304 0 09:36 pts/2 00:00:00 su - postgres
postgres 25339 25338 0 09:36 pts/2 00:00:00 -bash
root 25404 25122 0 09:43 pts/0 00:00:00 su - postgres
postgres 25405 25404 0 09:43 pts/0 00:00:00 -bash
root 25462 25442 0 09:45 pts/3 00:00:00 grep post
[root@ecs-yqb4 ~]#

2初步反应是有较慢的SQL语句，消耗系统资源导致的。通过下述SQL查看：

 select t1.datname, t2.query, t2.calls, t2.total_time, t2.total_time/t2.calls from pg_database t1, pg_stat_statements t2 where t1.oid=t2.dbid order by t2.total_time desc limit 10;

发现系统没有启用 pg_stat_statements这个扩展，于是，线上安装，

create extension pg_stat_statements;

并修改配置文件，/data/postgres/9.4.4/data/postgresql.conf：

shared_preload_libraries = ‘pg_stat_statements’ # (change requires restart)

修改该参数，需要重启数据库：

 pg_ctl restart -m fast;

再次，查看消耗系统资源的SQL。发现并没有如预期那样能看到消耗过高系统资源问题SQL语句存在。

3于是，进一步排查，发现是数据库的日志文件设置过少，导致数据库后台在做大量的checkpoint操作，导致数据库响应不及时，几乎是hang住挂起状态。

找到原因之后，再次修改数据库的配置文件：/data/postgres/9.4.4/data/postgresql.conf
增加日志文件到30个：
checkpoint_segments = 30 # in logfile segments, min 1, 16MB each

重新加载配置文件使之生效，或者重启数据库。

 
pg_ctl reload;

pg_ctl restart -m fast;

设置生效：

 
[postgres@ecs-yqb4 pg_xlog]$ pwd
/data/postgres/9.4.4/data/pg_xlog
[postgres@ecs-yqb4 pg_xlog]$ ll
-rw------- 1 postgres postgres 16777216 4月 9 10:24 000000010000000700000082
-rw------- 1 postgres postgres 16777216 4月 9 10:24 000000010000000700000083
-rw------- 1 postgres postgres 16777216 4月 9 10:25 000000010000000700000084
-rw------- 1 postgres postgres 16777216 4月 9 10:25 000000010000000700000085
-rw------- 1 postgres postgres 16777216 4月 9 10:25 000000010000000700000086
-rw------- 1 postgres postgres 16777216 4月 9 10:25 000000010000000700000087
-rw------- 1 postgres postgres 16777216 4月 9 10:26 000000010000000700000088
-rw------- 1 postgres postgres 16777216 4月 9 10:26 000000010000000700000089
-rw------- 1 postgres postgres 16777216 4月 9 10:26 00000001000000070000008A
-rw------- 1 postgres postgres 16777216 4月 9 10:26 00000001000000070000008B
-rw------- 1 postgres postgres 16777216 4月 9 10:27 00000001000000070000008C
-rw------- 1 postgres postgres 16777216 4月 9 10:27 00000001000000070000008D
-rw------- 1 postgres postgres 16777216 4月 9 10:27 00000001000000070000008E
-rw------- 1 postgres postgres 16777216 4月 9 10:27 00000001000000070000008F
-rw------- 1 postgres postgres 16777216 4月 9 10:28 000000010000000700000090
-rw------- 1 postgres postgres 16777216 4月 9 10:28 000000010000000700000091
-rw------- 1 postgres postgres 16777216 4月 9 10:28 000000010000000700000092
-rw------- 1 postgres postgres 16777216 4月 9 10:28 000000010000000700000093
-rw------- 1 postgres postgres 16777216 4月 9 10:29 000000010000000700000094
-rw------- 1 postgres postgres 16777216 4月 9 10:29 000000010000000700000095
-rw------- 1 postgres postgres 16777216 4月 9 10:29 000000010000000700000096
-rw------- 1 postgres postgres 16777216 4月 9 10:29 000000010000000700000097

4 很快，系统恢复正常使用。做个简单的记录，免于再次掉坑。

Java学习笔记001：Java中的变量

留下评论

在Java程序中，变量既可以是基本数据类型的某个值，也可以是指向某个对象的引用。

后半句，是我自己前段时间在学习Java的过程中，不曾理解到位的内容。这个跟面向过程的编程语言C，有很大的区别。是自己被C语言的思维模式固化了，因为在自己的脑子里，直观的反应就是类似于这样的变量：

 
int n1=10;
char c1='C';

接触Java，脑子里就得有后半句关于变量的概念。

一段关于Java的源代码如下：

 
public class JavaVariables{
	public static void main(String[] args){
		int n1=10;
		String s1="Hello,Java.";
		System.out.println(n1);
		System.out.println(s1);
	}
}

编译运行，如下：

 
$ javac JavaVariables.java 
$ java JavaVariables
10
Hello,Java.
$

失误的决策

留下评论

和妻子一起，经过辛苦打拼「工薪阶层的按部就班」，然后购置一套自住商品房。经过交房、装修、入住之后，发现：

1 周围环境空气极差，准确的讲应该是糟糕到令人厌恶的程度，没有干净的空气，周围化工厂的废气排放，臭气熏天，严重影响正常的生活，还不包括周围邻居装修排放的各种粉尘和装修污染「并没有责怪他人装修的意思」；

2 噪声极大，楼下不远处的公路上，大卡车、货车，昼夜不停的疾驰，高音喇叭带来的噪音污染，再给生活增加了一层厚重的云；

3 上班距离远，房子在郊区，交通不便利，二人都需要到二十几公里开外的地方上班。即使添置了家庭用车，并没有想象中的幸福感。估算上下班的时间，累计起来，两人平均每天需要消耗5-6小时的时间在路上。

房子俨然成为一个实打实的过夜留宿的地方，坦白讲，虽然每天住在自己家，躺在自家炕上，但是，心灵上并没有真正的归属感，不像是有了真正的栖息之地。

顺着人们一切的努力都是为了提升生活质量，获取更好的生活「当然并不都是这样」这个方向看过去，这一笔投资是一次不折不扣的失败决策。因为，投入了比较大量的经济、时间、精力成本购房买车之后。最终的结果，却是生活得比原来的我们更差了。生活质量不升反降，本来就不高的幸福指数打折了。

当然，如果从另外一个方向来看待上面的情况的话。毕竟，这是现实，是短期之内，我们自己暂时改变不了的事实，也只能心平静气的坦然接受。且，不抱怨，不吐槽。抱怨不解决任何问题，于事无补。谁不曾在投资决策上有过败笔，又有谁能确保在年轻时，对未来一定有先知先觉的能力？吐槽只能加深心中的怨气。所以，要努力做到及时止损，即使不能止损，也要学会闭嘴。

又，不论是谁的努力也好，奋斗也罢，不都是应该为了使自己和家人能够生活得比之前的自己更好一点儿吗？当然，肯定不能是为了比他人生活得更好。再沿着这条路往前走过去，问题的解决方案何在？

接受自己已经做出失败的投资决策的现实情况的基础上，要想尽一切办法来使自己变得更值钱。长期持续的投资自己，去学习新的知识和技能，不间断地向个人简历上尽可能的添加有分量的砝码。即使刚开始时，没有分量或者显示不出分量，也要添加。

对我们的未来和明天自信，且要盲目的自信。是的，那一天还没有到来。不过，终将来临。只是，需要我们不停地用自己的双手去尝试敲开那一天的门，然后，走过去，推开，迈进去。

 

 

解决Git object file is empty fatal的故障

留下评论

一 故障背景：

公司源码管理工具从SVN迁移到Git之后，Git源码服务器采用本地bitbucket托管。在一次bitbucket服务器所在虚拟主机由于存储空间吃紧，导致bitbucket意外宕机的故障之后。恢复虚拟主机，启动bitbucket之后，发现有某个项目的某个repository故障，导致开发同事无法提交代码，耽误事儿。

二 解决过程：

1 首先，在bitbucket上新建立1个项目工程以及repository给上述失败的项目使用；

2 其次，让该项目的开发同事，拿本地的git源码push到该新建的工程下对应的repository里；

3 然后，手工删除原故障的工程以及其下的所有repository，在控制台上进入该repository的时候，报错：

 

4 其次，再想办法如何解决该500错误：

‘/usr/local/git/bin/git cat-file -t refs/heads/master:’ exited with code 128 saying: error: object file ./objects/f4/22a78e5d8324e7c3fdaa5f9c88b02c7c7622dc is empty fatal: loose object f422a78e5d8324e7c3fdaa5f9c88b02c7c7622dc (stored in ./objects/f4/22a78e5d8324e7c3fdaa5f9c88b02c7c7622dc) is corrupt

 

 

a 进入bitbucket服务器的BITBUCKET_HOME,/data/atlassian/application-data/bitbucket下的 shared/data/repositories子目录：

[root@localhost repositories]# pwd

/data/atlassian/application-data/bitbucket/shared/data/repositories

[root@localhost repositories]# ll

总用量 508

drwxr-xr-x. 7 root root 4096 12月 13 23:20 100

drwxr-xr-x. 7 root root 4096 12月 13 23:21 101

drwxr-xr-x. 7 root root 4096 12月 13 23:20 105

drwxr-xr-x. 7 root root 4096 12月 13 23:21 107

drwxr-xr-x. 7 root root 4096 12月 13 23:20 108

drwxr-xr-x. 7 root root 4096 12月 13 23:20 115

drwxr-xr-x. 7 root root 4096 12月 13 23:21 116

drwxr-xr-x. 7 root root 4096 12月 13 23:21 117

drwxr-xr-x. 7 root root 4096 12月 13 23:21 118

drwxr-xr-x. 7 root root 4096 12月 13 23:20 119

drwxr-xr-x. 7 root root 4096 12月 13 23:20 120

drwxr-xr-x. 7 root root 4096 12月 13 23:21 121

drwxr-xr-x. 7 root root 4096 12月 13 23:21 122

drwxr-xr-x. 7 root root 4096 12月 13 23:21 123

drwxr-xr-x. 7 root root 4096 12月 13 23:20 124

drwxr-xr-x. 7 root root 4096 12月 13 23:21 125

drwxr-xr-x. 7 root root 4096 12月 13 23:20 126

drwxr-xr-x. 7 root root 4096 12月 13 23:21 127

drwxr-xr-x. 7 root root 4096 12月 13 23:20 128

drwxr-xr-x. 7 root root 4096 12月 13 23:21 129

drwxr-xr-x. 7 root root 4096 12月 13 23:21 13

drwxr-xr-x. 7 root root 4096 12月 13 23:20 130

drwxr-xr-x. 7 root root 4096 12月 13 23:20 131

drwxr-xr-x. 7 root root 4096 12月 13 23:21 132

drwxr-xr-x. 7 root root 4096 12月 13 23:21 133

drwxr-xr-x. 7 root root 4096 12月 13 23:20 134

drwxr-xr-x. 7 root root 4096 12月 13 23:20 135

drwxr-xr-x. 7 root root 4096 12月 13 23:21 136

drwxr-xr-x. 7 root root 4096 12月 13 23:21 137

drwxr-xr-x. 7 root root 4096 12月 13 23:20 138

drwxr-xr-x. 7 root root 4096 12月 13 23:21 139

drwxr-xr-x. 7 root root 4096 12月 13 23:20 140

drwxr-xr-x. 7 root root 4096 12月 13 23:21 141

drwxr-xr-x. 7 root root 4096 12月 13 23:20 142

drwxr-xr-x. 7 root root 4096 12月 13 23:20 143

drwxr-xr-x. 7 root root 4096 12月 13 23:21 144

drwxr-xr-x. 7 root root 4096 12月 13 23:20 145

drwxr-xr-x. 7 root root 4096 12月 13 23:21 146

drwxr-xr-x. 7 root root 4096 12月 13 23:20 147

drwxr-xr-x. 7 root root 4096 12月 13 23:21 148

drwxr-xr-x. 7 root root 4096 12月 13 23:20 149

drwxr-xr-x. 7 root root 4096 12月 13 23:21 15

drwxr-xr-x. 7 root root 4096 12月 13 23:21 150

drwxr-xr-x. 7 root root 4096 12月 13 23:20 153

drwxr-xr-x. 7 root root 4096 12月 13 23:21 154

drwxr-xr-x. 7 root root 4096 12月 13 23:21 156

drwxr-xr-x. 7 root root 4096 12月 13 23:21 157

drwxr-xr-x. 7 root root 4096 12月 13 23:21 158

drwxr-xr-x. 7 root root 4096 12月 13 23:20 159

drwxr-xr-x. 7 root root 4096 12月 13 23:21 16

drwxr-xr-x. 7 root root 4096 12月 13 23:21 166

drwxr-xr-x. 7 root root 4096 12月 13 23:20 167

drwxr-xr-x. 7 root root 4096 12月 13 23:21 168

drwxr-xr-x. 7 root root 4096 12月 13 23:21 169

drwxr-xr-x. 7 root root 4096 12月 13 23:21 170

drwxr-xr-x. 7 root root 4096 12月 13 23:21 171

drwxr-xr-x. 7 root root 4096 12月 13 23:20 172

drwxr-xr-x. 7 root root 4096 12月 13 23:20 173

drwxr-xr-x. 7 root root 4096 12月 13 23:21 174

drwxr-xr-x. 7 root root 4096 12月 13 23:21 175

drwxr-xr-x. 7 root root 4096 12月 13 23:21 176

drwxr-xr-x. 7 root root 4096 12月 13 23:21 177

drwxr-xr-x. 7 root root 4096 12月 13 23:20 178

drwxr-xr-x. 7 root root 4096 12月 13 23:20 179

drwxr-xr-x. 7 root root 4096 12月 13 23:21 180

drwxr-xr-x. 7 root root 4096 12月 13 23:21 181

drwxr-xr-x. 7 root root 4096 12月 13 23:20 182

drwxr-xr-x. 7 root root 4096 12月 13 23:21 183

drwxr-xr-x. 7 root root 4096 12月 13 23:20 184

drwxr-xr-x. 7 root root 4096 12月 13 23:21 185

drwxr-xr-x. 7 root root 4096 12月 13 23:21 186

drwxr-xr-x. 7 root root 4096 12月 13 23:20 187

drwxr-xr-x. 7 root root 4096 12月 13 23:21 188

drwxr-xr-x. 7 root root 4096 12月 13 23:21 189

drwxr-xr-x. 7 root root 4096 12月 13 23:21 190

drwxr-xr-x. 7 root root 4096 12月 13 23:21 192

drwxr-xr-x. 7 root root 4096 12月 13 23:21 193

drwxr-xr-x. 7 root root 4096 12月 13 23:21 194

drwxr-xr-x. 7 root root 4096 12月 13 23:21 195

drwxr-xr-x. 7 root root 4096 12月 13 23:20 196

drwxr-xr-x. 7 root root 4096 12月 13 23:21 197

drwxr-xr-x. 7 root root 4096 12月 13 23:21 27

drwxr-xr-x. 7 root root 4096 12月 13 23:21 28

drwxr-xr-x. 7 root root 4096 12月 13 23:20 29

drwxr-xr-x. 7 root root 4096 12月 13 23:21 3

drwxr-xr-x. 7 root root 4096 12月 13 23:21 40

drwxr-xr-x. 7 root root 4096 12月 13 23:21 41

drwxr-xr-x. 7 root root 4096 12月 13 23:20 47

drwxr-xr-x. 7 root root 4096 12月 13 23:21 51

drwxr-xr-x. 7 root root 4096 12月 13 23:21 52

drwxr-xr-x. 7 root root 4096 12月 13 23:21 53

drwxr-xr-x. 9 root root 4096 12月 13 23:21 56

drwxr-xr-x. 7 root root 4096 12月 13 23:21 57

drwxr-xr-x. 7 root root 4096 12月 13 23:21 58

drwxr-xr-x. 7 root root 4096 12月 13 23:21 59

drwxr-xr-x. 7 root root 4096 12月 13 23:21 60

drwxr-xr-x. 7 root root 4096 12月 13 23:21 61

drwxr-xr-x. 7 root root 4096 12月 13 23:20 62

drwxr-xr-x. 7 root root 4096 12月 13 23:21 63

drwxr-xr-x. 7 root root 4096 12月 13 23:21 64

drwxr-xr-x. 7 root root 4096 12月 13 23:20 65

drwxr-xr-x. 9 root root 4096 12月 13 23:21 66

drwxr-xr-x. 7 root root 4096 12月 13 23:21 67

drwxr-xr-x. 7 root root 4096 12月 13 23:20 68

drwxr-xr-x. 7 root root 4096 12月 13 23:21 69

drwxr-xr-x. 7 root root 4096 12月 13 23:20 70

drwxr-xr-x. 7 root root 4096 12月 13 23:21 71

drwxr-xr-x. 7 root root 4096 12月 13 23:21 72

drwxr-xr-x. 7 root root 4096 12月 13 23:20 73

drwxr-xr-x. 7 root root 4096 12月 13 23:21 74

drwxr-xr-x. 7 root root 4096 12月 13 23:21 75

drwxr-xr-x. 7 root root 4096 12月 13 23:21 81

drwxr-xr-x. 7 root root 4096 12月 13 23:21 82

drwxr-xr-x. 7 root root 4096 12月 13 23:21 83

drwxr-xr-x. 7 root root 4096 12月 13 23:20 84

drwxr-xr-x. 7 root root 4096 12月 13 23:21 85

drwxr-xr-x. 7 root root 4096 12月 13 23:21 86

drwxr-xr-x. 7 root root 4096 12月 13 23:21 87

drwxr-xr-x. 7 root root 4096 12月 13 23:20 88

drwxr-xr-x. 7 root root 4096 12月 13 23:20 89

drwxr-xr-x. 7 root root 4096 12月 13 23:21 90

drwxr-xr-x. 7 root root 4096 12月 13 23:21 91

drwxr-xr-x. 7 root root 4096 12月 13 23:21 92

drwxr-xr-x. 7 root root 4096 12月 13 23:21 93

drwxr-xr-x. 7 root root 4096 12月 13 23:20 94

drwxr-xr-x. 7 root root 4096 12月 13 23:20 98

drwxr-xr-x. 7 root root 4096 12月 13 23:21 99

[root@localhost repositories]#

b 查找哪个repository包含上述报错的“22a78e5d8324e7c3fdaa5f9c88b02c7c7622dc”关键字

[root@localhost repositories]# find  ./ |xargs grep -ri “22a78e5d8324e7c3fdaa5f9c88b02c7c7622dc”

./66/refs/heads/master:f422a78e5d8324e7c3fdaa5f9c88b02c7c7622dc

./66/refs/heads/master:f422a78e5d8324e7c3fdaa5f9c88b02c7c7622dc

./66/refs/heads/master:f422a78e5d8324e7c3fdaa5f9c88b02c7c7622dc

./66/refs/heads/master:f422a78e5d8324e7c3fdaa5f9c88b02c7c7622dc

[root@localhost repositories]#

 

c 执行git fsck

[root@localhost repositories]# cd 66

[root@localhost 66]# git fsck

检查对象目录中: 100% (256/256), 完成.

error: object file ./objects/1a/d1162a6381f39960d7efb38aee8e989965489e is empty

error: object file ./objects/1a/d1162a6381f39960d7efb38aee8e989965489e is empty

fatal: loose object 1ad1162a6381f39960d7efb38aee8e989965489e (stored in ./objects/1a/d1162a6381f39960d7efb38aee8e989965489e) is corrupt

[root@localhost 66]#

d 然后到控制台，依然报错（此步骤非必须）：

 

e 删除包含关键字为66的repository：

[root@localhost repositories]# rm -rf 66

[root@localhost repositories]#

f 最后到控制台上删除包含错误的repository以及其工程project。

删除之后，之前报错的repository不再出现。

三 小结解决思路

1在Git服务器上创建新的项目和对应的repository；

2 手工把本地源码push到该新建的项目下；

3 删除出错的旧工程及其所有的repository；

4 删除出错，可以到Git服务器的BITBUCKET_HOME,/data/atlassian/application-data/bitbucke/shared/data/repositories子目录下，通过将包含错误信息的repository手工删除来处理。

Linux环境设置zookeeper、memcached、activemq、dubbo自动启动

留下评论

一 zookeeper

1 修改zkServer.sh(/usr/local/zookeeper-3.4.5/bin/zkServer.sh)文件的第一行：

#!/usr/bin/env bash

为：

#!/bin/bash

# description: Zookeeper Start Stop Restart

# processname: zookeeper

# chkconfig: 244 30 80

 

2 修改：

# use POSTIX interface, symlink is followed automatically

ZOOBIN=”${BASH_SOURCE-$0}”

ZOOBIN=`dirname ${ZOOBIN}`

ZOOBINDIR=`cd ${ZOOBIN}; pwd`

 

if [ -e “$ZOOBIN/../libexec/zkEnv.sh” ]; then

为

# use POSTIX interface, symlink is followed automatically

ZOOSH=`readlink $0`

ZOOBIN=`dirname $ZOOSH`

ZOOBINDIR=`cd $ZOOBIN; pwd`

ZOO_LOG_DIR=`echo $ZOOBIN`

 

if [ -e “$ZOOBIN/../libexec/zkEnv.sh” ]; then

 

3 创建软链接：

[root@dev-middleware ~]# ln -s /usr/local/zookeeper-3.4.5/bin/zkServer.sh  /etc/init.d/zookeeper

 

4 添加自动启动

[root@dev-middleware ~]# chkconfig –list zookeeper

zookeeper 服务支持 chkconfig，但它在任何级别中都没有被引用(运行“chkconfig –add zookeeper”)

[root@dev-middleware ~]# chkconfig –add zookeeper

[root@dev-middleware ~]# chkconfig –level 2345 zookeeper on

[root@dev-middleware ~]# chkconfig –list zookeeper

zookeeper       0:关闭  1:关闭  2:启用  3:启用  4:启用  5:启用  6:关闭

[root@dev-middleware ~]#

 

5 参考

http://positivealex.github.io/blog/posts/how-to-install-zookeeper-as-service-on-centos/

二 memcached

[root@dev-middleware ~]# chkconfig –list memcached

memcached 服务支持 chkconfig，但它在任何级别中都没有被引用(运行“chkconfig –add memcached”)

[root@dev-middleware ~]# chkconfig –add memcached

[root@dev-middleware ~]# chkconfig –level 2345 memcached on

[root@dev-middleware ~]# chkconfig –list memcached

memcached       0:关闭  1:关闭  2:启用  3:启用  4:启用  5:启用  6:关闭

[root@dev-middleware ~]#

三 activemq

1 修改文件activemq (/usr/local/apache-activemq-5.9.0/bin/activemq)，第1行：

#!/bin/sh

为：

#!/bin/sh

### BEGIN INIT INFO

# Provides:             activemq

# Required-Start:       $remote_fs $syslog

# Required-Stop:        $remote_fs $syslog

# Default-Start:        2 3 4 5

# Default-Stop:         0 6

# Short-Description:    ActiveMQ server

### END INIT INFO

 

2 创建软链接：

[root@dev-middleware bin]# ln -s /usr/local/apache-activemq-5.9.0/bin/activemq /etc/init.d/activemq

[root@dev-middleware bin]#

 

3 添加自动启动

[root@dev-middleware bin]# chkconfig –list activemq

activemq 服务支持 chkconfig，但它在任何级别中都没有被引用(运行“chkconfig –add activemq”)

[root@dev-middleware bin]# chkconfig –add activemq

[root@dev-middleware bin]# chkconfig –level 2345 activemq on

[root@dev-middleware bin]# chkconfig –list activemq

activemq        0:关闭  1:关闭  2:启用  3:启用  4:启用  5:启用  6:关闭

[root@dev-middleware bin]#

 

4 参考

http://www.liaoxuefeng.com/article/0013738918072162b1c2a36eb0f40e690d3902acf60c8fb000

四 dubbo

 

[root@dev-middleware ~]# ll /etc/init.d/tomcat-dubbo-admin

-rwxr-xr-x 1 root root 1969 9月   8 13:49 /etc/init.d/tomcat-dubbo-admin

[root@dev-middleware ~]# /etc/init.d/tomcat-dubbo-admin

start/stop

[root@dev-middleware ~]# chkconfig –list tomcat-dubbo-admin

tomcat-dubbo-admin 服务支持 chkconfig，但它在任何级别中都没有被引用(运行“chkconfig –add tomcat-dubbo-admin”)

[root@dev-middleware ~]# chkconfig –add tomcat-dubbo-admin

[root@dev-middleware ~]# chkconfig –level 2345 tomcat-dubbo-admin on

[root@dev-middleware ~]# chkconfig –list tomcat-dubbo-admin

tomcat-dubbo-admin      0:关闭  1:关闭  2:启用  3:启用  4:启用  5:启用  6:关闭

[root@dev-middleware ~]#

Linux环境配置SFTP小结

Linux环境配置SFTP小结有2条评论

说明：简明扼要的记录在Linux环境上配置SFTP的注意事项，主要是自己在该问题的小细节上犯过几次同样的错误，我必须要动手把它记录、写下来，自己还要时不时的翻看一下，避免在同样的问题上连续跌倒(*^__^*)

一 配置步骤

1.创建SFTP用户组

groupadd sftp

2.添加用户并设置为sftp组

 useradd -g sftp -s /sbin/nologin -M  sftpUser

其中：（/sbin/nologin为禁止登录shell的用户，即该用户sftpUser无法获取shell，也就限制其登录主机）

3.设置用户密码

passwd sftpUser

4.创建用户目录，并设置权限

cd /home

mkdir sftpUserDir

chown root:sftp sftpUserDir

chmod 755 sftpUserDir

这里：设置sftp用户sftpUser将来通过SFTP来上传、下载的目录为/home/sftpUserDir。同时，设置该目录目录/home/sftpUserDir的所属用户和组为root:sftp,且其权限务必为755，否则SFTP会报错！

5.修改SSH配置

修改/etc/ssh/sshd_config配置文件

修改Subsystem为：

Subsystem sftp internal-sftp

6.在sshd_config添加用户配置

Match User sftpUser  #配置允许SFTP操作的用户名为sftpUser

Match Group sftp   #配置允许SFTP操作的用户组为sftp

X11Forwarding no

AllowTcpForwarding no

ForceCommand internal-sftp

ChrootDirectory /home/sftpUserDir  #配置用户的根目录

说明：Match User sftpUser和Match Group sftp的配置，可以有选择性的配置，也可以组合配置。中间3行为允许SFTP转发的配置。

7.最后重启SSH

/etc/init.d/ssh restart

二 验证测试

在其它的机器上执行：

sftp sftpUser@SFTP_server_IP

三 小结

1  ChrootDirectory 的所有父目录的权限最高只能是755 ，否则会抛出下述错误！

Read from remote host 172.16.xx.xxx: Connection reset by peer

Couldn’t read packet: Connection reset by peer

2 SFTP Permission denied处理

com.jcraft.jsch.SftpException: Permission denied

问题的原因是，SFTP服务器的SELINUX没关闭。

解决办法：

查看SELINUX的配置：getenforce

关闭SELINUX：setenforce 0

 勿以善小而不为，不要以为不起眼的小问题就不够引起你对它的重视。

Linux环境SSH免密配置小结

留下评论

场景：

Server a：IP 为172.16.6.1上有1个用户root；

Server b：Ip为172.16.6.2上有3个用户root、tomcat、deploy；

Q1：

Server a上能不能配置以tomcat、deploy通过SSH免密登录到Server b ?

A1:

完全可以。在1台机器上，能否以某个指定用户通过SSH免密登录到另外1台目标机器上，与当前机器上是否存在该指定用户无关。这一点是我之前不曾知道的，总以为，发起SSH请求的机器上也必须要有对应的用户存在。从前，在配置Oracle RAC数据库时，多个节点上都有oracle用户存在，在配置oracle用户SSH免密登录的时候，产生的误区就是以为SSH免密登录的场景下，源端和目标端都必须要有对应的用户存在。原来，自己误导自己已多年。

Q2：

如何配置Q1上所说的免密登录？

A2：

1

Server a上，以root依次执行：

ssh-keygen –t rsa;

ssh-keygen –t dsa;

分别生成RSA、DSA加密算法的秘钥。否则可能会遭遇下述错误：

/usr/bin/ssh-copy-id: ERROR: No identities found

2

ssh-copy-id tomcat@172.16.6.2

ssh-copy-id deploy@172.16.6.2

依次执行上还命令。且分别输入tomcat、deploy用户的口令。

3

当前机器上以root用户执行 ssh tomcat@172.16.6.2 即可实现以tomcat的身份执行SSH免密登录到172.16.6.2机器上。deploy用户同。

Q3

上述场景里，假设Server a上也有tomcat、deploy用户存在，且已经配置完成可以以root用户发起，向Server b的ssh tomcat@172.16.6.2的免密登录的前提下，那么在Server a上以tomcat用户发起向Server b的ssh tomcat@172.16.6.2的免密登录可行吗？

A3

绝对不可以。如果需要在Server a上以tomcat用户发起向Server b的ssh tomcat@172.16.6.2的免密登录，那么必须在Server a上，以tomcat用户登录，重新执行上述A2的免密登录配置。

 

小结：

1 源端机器发起向目标端机器的免密登录，源端机器上是否存在与目标端机器上的SSH用户无关；如：源端机器上只有root用户，即使不存在tomcat用户，那么也可以以root用户发起ssh tomcat@目标机器的免密登录；

2 即使源端机器可以以u1用户执行ssh u2@目标机器IP的免密登录，那么源端机器的u2用户也不一定能够顺利执行ssh u2@目标机器IP的免密登录。这取决于，源端机器上的u2用户，是否已经配置SSH到目标机器的免密登录。