解决 centos yum update TypeError: unsubscriptable object 的问题

近日在运行系统更新命令yum update时候出现了如下错误提示:
Component: pirut
Summary: TBe8ae967a sqlitesack.py:94:_read_db_obj:TypeError: unsubscriptable object

Traceback (most recent call last):

……..//此处省略部分内容

TypeError: unsubscriptable object

Local variables in innermost frame:
item: name
db_obj: None

这个问题是由于yum的原数据损坏导致的,需要先删除原数据和数据库缓存,然后重建,问题即可解决
解决方法,依次运行以下命令:

yum clean metadata //通常执行这句就能解决,如果这句不能解决问题,继续下面操作
yum clean dbcache
yum makecache

mysql5配置主从库【转】

安装mysql请参考以下文章
http://blog.sina.com.cn/s/blog_4fe1599c01000b7t.html

下面直接记录下配置主从库的操作:
1.在主库建立要同步的数据库,建立主库的帐号和修改主库配置
首先连接上数据库
mysql -S /tmp/mysql-3108.sock
创建测试同步的数据库,”create database sinatest;”
然后建立负责同步的用户
grant all on *.* to ali@”%” Identified by “abc111”;
然后修改/data2/ali/mysql3308/my.cnf主库的配置,增加
binlog-do-db=sinatest

2.修改从库配置
然后修改/data2/ali/mysql3309/my.cnf主库的配置,增加

master-host=127.0.0.1
master-user=ali
master-password=abc111
master-port=3308
server-id=2
master-connect-retry=60
replicate-do-db=sinatest
log-slave-updates

3.重启mysql

/usr/local/mysql/bin/mysqld_safe --defaults-file=/data2/ali/mysql3308/my.cnf  --user=root &
/usr/local/mysql/bin/mysqld_safe --defaults-file=/data2/ali/mysql3309/my.cnf  --user=root &

4.在主库创建数据表,检查从库是否同步正确
进入主库,创建数据表
mysql -S /tmp/mysql-3108.sock

CREATE TABLE if not exists ali_test_00 (
`id` int(11) unsigned NOT NULL auto_increment,
`my_id` varchar(16) binary NOT NULL default '',
`my_title` varchar(96) binary NOT NULL default '',
`status` int(11) unsigned NOT NULL default '1',
PRIMARY KEY  (`id`),
KEY `my_id` (`my_id`)
) TYPE=MyISAM;

insert into ali_test_00 values (null,32,"aliwwww",1);
insert into ali_test_00 values (null,32,"aliwwww",1);

然后检查从库是否有该表和表中是否有数据

SHOW SLAVE STATUS;
SHOW MASTER STATUS;
slave stop;
slave start;

CHANGE MASTER TO
MASTER_HOST='127.0.0.1',
MASTER_USER='ali',
MASTER_PASSWORD='abc111',
MASTER_LOG_FILE='mysql-bin.000003',
MASTER_LOG_POS=0;

MYSQL 主从服务器配置工作原理【转】

一、 主从配置的原理:
Mysql的 Replication 是一个异步的复制过程,从一个 Mysql instace(我们称之为 Master)复制到另一个
Mysql instance(我们称之 Slave)。在 Master 与 Slave
之间的实现整个复制过程主要由三个线程来完成,其中两个线程(Sql线程和IO线程)在 Slave 端,另外一个线程(IO线程)在 Master
端。
要实现 MySQL 的 Replication ,首先必须打开 Master 端的Binary
Log(mysql-bin.xxxxxx)功能,否则无法实现。因为整个复制过程实际上就是Slave从Master端获取该日志然后再在自己身上完全
顺序的执行日志中所记录的各种操作。打开 MySQL 的 Binary Log 可以通过在启动 MySQL Server 的过程中使用
“—log-bin” 参数选项,或者在 my.cnf 配置文件中的 mysqld 参数组([mysqld]标识后的参数部分)增加
“log-bin” 参数项。
MySQL 复制的基本过程如下:
1. Slave 上面的IO线程连接上 Master,并请求从指定日志文件的指定位置(或者从最开始的日志)之后的日志内容;

2. Master 接收到来自 Slave 的 IO 线程的请求后,通过负责复制的 IO
线程根据请求信息读取指定日志指定位置之后的日志信息,返回给 Slave 端的 IO
线程。返回信息中除了日志所包含的信息之外,还包括本次返回的信息在 Master 端的 Binary Log 文件的名称以及在 Binary
Log 中的位置;
3. Slave 的 IO 线程接收到信息后,将接收到的日志内容依次写入到 Slave 端的Relay
Log文件(mysql-relay-bin.xxxxxx)的最末端,并将读取到的Master端的bin-log的文件名和位置记录到master-
info文件中,以便在下一次读取的时候能够清楚的高速Master“我需要从某个bin-log的哪个位置开始往后的日志内容,请发给我”

4. Slave 的 SQL 线程检测到 Relay Log 中新增加了内容后,会马上解析该 Log 文件中的内容成为在 Master
端真实执行时候的那些可执行的 Query 语句,并在自身执行这些 Query。这样,实际上就是在 Master 端和 Slave
端执行了同样的 Query,所以两端的数据是完全一样的。

二、 设置mysql主从配置的优点:
1、 解决web应用系统,数据库出现的性能瓶颈,采用数据库集群的方式来实现查询负载;一个系统中数据库的查询操作比更新操作要多得多,通过多台查询服务器将数据库的查询分担到不同的查询服务器上从而提高查询效率。
2、 Mysql数据库支持数据库的主从复制功能,使用主数据库进行数据的插入、删除与更新操作,而从数据库则专门用来进行数据查询操作,这样可以将更新操作和查询操作分担到不同的数据库上,从而提高了查询效率。

三、 主从数据库服务器的配置
1、 主数据库服务器的配置
(1)、修改mysql的配置文件(/etc/my.cnf)在配置文件中设置:
server-id    = 1 ###每一个数据库服务器都要制定一个唯一的server-id,通常主服务器制定为1。
log-bin=mysql-bin     ###mysql进行主从复制是通过二进制的日志文件来进行的,所以必须开启mysql的日志功能
(这个是/etc/my.cnf的默认配置,保持不变即可)
(2)、GRANT REPLICATION SLAVE ON *.* TO ‘ replication’@’172.28.3.41’ IDENTIFIED BY ‘koncept’;        #####给主数据库服务器授予一个可以进行复制的用户,172.28.3.41为从服务器的IP,这样从服务器就能有钱先来访问主数据库服务器
2、从数据库服务器的设置
修改数据库配置文件/etc/my.cnf,配置如下内容:
#server-id    = 1   ####必须把server-id    = 1注释掉,
server-id    = 2   ####设置从的ID号
master-host     =   172.28.3.43   #####设置主服务器的IP
master-user     = replication   #####设置连接主服务器的用户名
master-password = concept     #####设置连接主服务器的密码
replicate-do-db=imtest0   ######设置你要同步的数据库,可以设置多个
####就是我们前面建的用户名和密码,另外如果有端口号的变化还要配置端口
master-port     =   <port> 配置成你设置的端口就OK了!
3、分别重新启动主从服务器 #### 如果不重新启动主服务器在后面查看status的时候会出现问题!
4在从服务器上登录mysql,输入:show slave status\G   如果发现有:
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
就说明已经成功了,如果这两个选项不全是Yes,那就说明你钱面的某个配置错了,
我做的时候没有把主服务器重启,就出现   Slave_IO_Running: NO。重启后好了!

四、 监控服务器的状态
1、 监控主服务器的状态
可通过show master status来监控主服务器的状态,内容如下:
+——————+———-+————–+——————+
| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+——————+———-+————–+——————+
| mysql-bin.000003 |     1164 |              |                |
+——————+———-+————–+——————+
#####其中File表示日志文件记录,Position表示日志文件的位置,这个也是数据库执行复制操作的必须标识,后面两字段表示复制的数据库名和不复制的数据库名,也可以在配置文件中你进行配置。
2、 监控从服务器的状态
可以通过:show slave status\G来查看,另外如果从数据库在复制的过程中出现问题,可以通过命令reset slave从数据库服务器复制的线程,从数据库服务器的通常操作命令有:
start slave;   ####启动复制线程
stop slave;   ####停止复制线程
reset slave;   ####重置复制线程
change master to; ###动态改变到主服务器的配置

硬盘ext2/3文件系统superblock损坏修复试验【转】

撰写者信息:

Alin Fang (Fang Yunlin)

MSN: [email protected]

G Talk: [email protected]

Blog: http://www.alinblog.cn/

修改日期:

9 Oct, 2008

2次修改

版权:

GNU

声明:

本人实验笔记,非权威文档。如有错误请告知。十分感谢!

实验笔记:

首先大家可能遇到过这样的情况:

[root@dhcp-0-142 ~]# mount /dev/sdb1 /mnt/sdb1

mount: wrong fs type, bad option, bad superblock on /dev/sdb1,

missing codepage or other error

In some cases useful info is found in syslog – try

dmesg | tail or so

[root@dhcp-0-142 ~]#

这种情况一般为superblock损坏的概率很大。

superblock是什么?

分区的第一块superblock位于分区的第二块block

如果分区的blocksize1024,则superblock位于[1024, 2048)之间。

ext2文件系统的结构请参考这个网站,写的非常清楚:

http://homepage.smc.edu/morgan_david/cs40/analyze-ext2.htm

这个是superblock的结构,摘自:

http://homepage.smc.edu/morgan_david/cs40/analyze-ext2.htm

继续刚才的话题。我/dev/sdb1挂载不上了。

所以我做了如下操作:

[root@dhcp-0-142 ~]# dumpe2fs /dev/sdb1

dumpe2fs 1.39 (29-May-2006)

Filesystem volume name: <none>

Last mounted on: <not available>

Filesystem UUID: c3800df3-5c34-4b53-8144-94029b5736d8

Filesystem magic number: 0xEF53

Filesystem revision #: 1 (dynamic)

Filesystem features: has_journal resize_inode dir_index filetype sparse_super

Default mount options: (none)

Filesystem state: clean with errors

Errors behavior: Continue

Filesystem OS type: Linux

Inode count: 0

Block count: 0

Reserved block count: 0

Free blocks: 20926971

Free inodes: 4705752

First block: 1

Block size: 1024

Fragment size: 1024

Reserved GDT blocks: 256

Blocks per group: 8192

Fragments per group: 8192

Inodes per group: 2008

Inode blocks per group: 251

Filesystem created: Tue Oct 7 19:18:08 2008

Last mount time: n/a

Last write time: Tue Oct 7 19:29:39 2008

Mount count: 0

Maximum mount count: 20

Last checked: Tue Oct 7 19:18:08 2008

Check interval: 15552000 (6 months)

Next check after: Sun Apr 5 19:18:08 2009

Reserved blocks uid: 0 (user root)

Reserved blocks gid: 0 (group root)

First inode: 11

Inode size: 128

Journal inode: 8

Default directory hash: tea

Directory Hash Seed: 7f7e1c41-5cae-4f23-9873-877991751ccb

Journal backup: inode blocks

dumpe2fs: Illegal inode number while reading journal inode

[root@dhcp-0-142 ~]#

根据Blocks per group: 8192的信息,我定位了第一个备份superblock的位置为8193

所以我做如下操作:

[root@dhcp-0-142 ~]# fsck -b 8193 /dev/sdb1

fsck 1.39 (29-May-2006)

e2fsck 1.39 (29-May-2006)

/dev/sdb1 was not cleanly unmounted, check forced.

Pass 1: Checking inodes, blocks, and sizes

Pass 2: Checking directory structure

Pass 3: Checking directory connectivity

Pass 4: Checking reference counts

Pass 5: Checking group summary information

/dev/sdb1: ***** FILE SYSTEM WAS MODIFIED *****

/dev/sdb1: 11/26104 files (9.1% non-contiguous), 8966/104388 blocks

[root@dhcp-0-142 ~]# mount /dev/sdb1 /mnt/sdb1

[root@dhcp-0-142 ~]# ls /mnt/sdb1

lost+found

[root@dhcp-0-142 ~]#

superblock已经修复,文件系统挂载正常。

之所以这么做,是有依据的。

ext2/3文件系统在创建文件系统的时候会创建若干个superblock的备份存放于特定位置。

[root@dhcp-0-142 ~]# dumpe2fs /dev/sdb1 | grep –before-context=1 superblock

dumpe2fs 1.39 (29-May-2006)

Group 0: (Blocks 1-8192)

Primary superblock at 1, Group descriptors at 2-2

Group 1: (Blocks 8193-16384)

Backup superblock at 8193, Group descriptors at 8194-8194

Group 3: (Blocks 24577-32768)

Backup superblock at 24577, Group descriptors at 24578-24578

Group 5: (Blocks 40961-49152)

Backup superblock at 40961, Group descriptors at 40962-40962

Group 7: (Blocks 57345-65536)

Backup superblock at 57345, Group descriptors at 57346-57346

Group 9: (Blocks 73729-81920)

Backup superblock at 73729, Group descriptors at 73730-73730

[root@dhcp-0-142 ~]#

从上面操作可以看出,在第13479这几个Block Group上存放有superblock备份。

什么是Block Groupext2/3文件系统为了提高磁盘寻道效率,把inode table等信息按照Inodes per group分成若干组存放,而没有全部放在一起。

此图摘自:http://homepage.smc.edu/morgan_david/cs40/analyze-ext2.htm

Inodes per group信息相见命令:

[root@dhcp-0-142 ~]# dumpe2fs /dev/sdb1 | grep ‘Inodes per group’

dumpe2fs 1.39 (29-May-2006)

Inodes per group: 2008

[root@dhcp-0-142 ~]#

有些文件系统superblock损坏的很厉害。连dumpe2fstune2fs都看不到信息。

[root@dhcp-0-175 ~]# dd if=/dev/zero of=/dev/sdb1 bs=1 count=1024 seek=1024

1024+0 records in

1024+0 records out

1024 bytes (1.0 kB) copied, 0.0228272 seconds, 44.9 kB/s

[root@dhcp-0-175 ~]# dumpe2fs /dev/sdb1

dumpe2fs 1.39 (29-May-2006)

dumpe2fs: Bad magic number in super-block while trying to open /dev/sdb1

Couldn’t find valid filesystem superblock.

[root@dhcp-0-175 ~]# tune2fs -l /dev/sdb1

tune2fs 1.39 (29-May-2006)

tune2fs: Bad magic number in super-block while trying to open /dev/sdb1

Couldn’t find valid filesystem superblock.

[root@dhcp-0-175 ~]#

这时候我们根本无法从dumpe2fstune2fs看到Backup superblock的位置。

我们可以尝试从superblock的结构来猜测superblock的位置(superblock结构见上图)。

我们从superblock结构可以知道,卷标volume name存放于superblock中。所以如果文件系统有设置卷标,那么我们可以尝试从卷标来定位superblock

我们用hexdump把文件系统dump出来:

[root@dhcp-0-175 ~]# hexdump -C /dev/sdb1 > /var/sdb1.hexdump

[root@dhcp-0-175 ~]#

我们已知 /dev/sdb1的卷标是sdb1(如果不知道卷标或者没有设置卷标,那么我就没办法了)

我们搜索sdb1,搜到结果如下:

我们猜测这里就是备份superblock的位置。

卷标起始位置是0x18000078。由于superblock结构里volume name位于0x78的位置,所以我们可以猜测备份superblock的起始位置是0x18000078 – 0x78 = 0x18000000

由于blocksize位于superblock[0x18, 0x22)的位置,这里的值是0x0002,得出blocksize0x0400 x ( 0x00020x0002 ) = 0x1000 = 4096

( [0x18, 0x22) 处值nblocksize的关系是 blocksize = 0x0400 x 0x0002n此公式感谢得新倾情赞助)

而备份superblock的偏移量为offset / blocksize,即0x18000000 / 0x1000 = 0x00018000 = 98304

因此我们执行:

[root@dhcp-0-175 ~]# fsck.ext3 -b 98304 /dev/sdb1

e2fsck 1.39 (29-May-2006)

sdb1 was not cleanly unmounted, check forced.

Pass 1: Checking inodes, blocks, and sizes

Pass 2: Checking directory structure

Pass 3: Checking directory connectivity

Pass 4: Checking reference counts

Pass 5: Checking group summary information

sdb1: ***** FILE SYSTEM WAS MODIFIED *****

sdb1: 11/123648 files (9.1% non-contiguous), 8298/246991 blocks

[root@dhcp-0-175 ~]#

这样文件系统就有给修复的可能性了。

测试一下:

[root@dhcp-0-175 ~]# dumpe2fs /dev/sdb1

dumpe2fs 1.39 (29-May-2006)

Filesystem volume name: sdb1

Last mounted on: <not available>

Filesystem UUID: 0293bd85-b911-43bf-853e-6588b3eaaf39

Filesystem magic number: 0xEF53

Filesystem revision #: 1 (dynamic)

Filesystem features: has_journal resize_inode dir_index filetype sparse_super large_file

Default mount options: (none)

Filesystem state: clean

Errors behavior: Continue

Filesystem OS type: Linux

Inode count: 123648

Block count: 246991

Reserved block count: 12349

Free blocks: 238693

Free inodes: 123637

First block: 0

Block size: 4096

Fragment size: 4096

Reserved GDT blocks: 60

Blocks per group: 32768

Fragments per group: 32768

Inodes per group: 15456

Inode blocks per group: 483

Filesystem created: Wed Oct 8 12:49:09 2008

Last mount time: n/a

Last write time: Wed Oct 8 12:52:10 2008

Mount count: 0

Maximum mount count: 28

Last checked: Wed Oct 8 12:52:10 2008

Check interval: 15552000 (6 months)

Next check after: Mon Apr 6 12:52:10 2009

Reserved blocks uid: 0 (user root)

Reserved blocks gid: 0 (group root)

First inode: 11

Inode size: 128

Journal inode: 8

Default directory hash: tea

Directory Hash Seed: 2efa124c-dde6-4046-9181-a05b7e6d182a

Journal backup: inode blocks

Journal size: 16M

Group 0: (Blocks 0-32767)

Primary superblock at 0, Group descriptors at 1-1

Reserved GDT blocks at 2-61

Block bitmap at 62 (+62), Inode bitmap at 63 (+63)

Inode table at 64-546 (+64)

28113 free blocks, 15445 free inodes, 2 directories

Free blocks: 4655-32767

Free inodes: 12-15456

Group 1: (Blocks 32768-65535)

Backup superblock at 32768, Group descriptors at 32769-32769

Reserved GDT blocks at 32770-32829

Block bitmap at 32830 (+62), Inode bitmap at 32831 (+63)

Inode table at 32832-33314 (+64)

32221 free blocks, 15456 free inodes, 0 directories

Free blocks: 33315-65535

Free inodes: 15457-30912

Group 2: (Blocks 65536-98303)

Block bitmap at 65536 (+0), Inode bitmap at 65537 (+1)

Inode table at 65538-66020 (+2)

32283 free blocks, 15456 free inodes, 0 directories

Free blocks: 66021-98303

Free inodes: 30913-46368

Group 3: (Blocks 98304-131071)

Backup superblock at 98304, Group descriptors at 98305-98305

Reserved GDT blocks at 98306-98365

Block bitmap at 98366 (+62), Inode bitmap at 98367 (+63)

Inode table at 98368-98850 (+64)

32221 free blocks, 15456 free inodes, 0 directories

Free blocks: 98851-131071

Free inodes: 46369-61824

Group 4: (Blocks 131072-163839)

Block bitmap at 131072 (+0), Inode bitmap at 131073 (+1)

Inode table at 131074-131556 (+2)

32283 free blocks, 15456 free inodes, 0 directories

Free blocks: 131557-163839

Free inodes: 61825-77280

Group 5: (Blocks 163840-196607)

Backup superblock at 163840, Group descriptors at 163841-163841

Reserved GDT blocks at 163842-163901

Block bitmap at 163902 (+62), Inode bitmap at 163903 (+63)

Inode table at 163904-164386 (+64)

32221 free blocks, 15456 free inodes, 0 directories

Free blocks: 164387-196607

Free inodes: 77281-92736

Group 6: (Blocks 196608-229375)

Block bitmap at 196608 (+0), Inode bitmap at 196609 (+1)

Inode table at 196610-197092 (+2)

32283 free blocks, 15456 free inodes, 0 directories

Free blocks: 197093-229375

Free inodes: 92737-108192

Group 7: (Blocks 229376-246990)

Backup superblock at 229376, Group descriptors at 229377-229377

Reserved GDT blocks at 229378-229437

Block bitmap at 229438 (+62), Inode bitmap at 229439 (+63)

Inode table at 229440-229922 (+64)

17068 free blocks, 15456 free inodes, 0 directories

Free blocks: 229923-246990

Free inodes: 108193-123648

[root@dhcp-0-175 ~]# mount /dev/sdb1 /mnt

[root@dhcp-0-175 ~]# ls /mnt

lost+found

[root@dhcp-0-175 ~]#

看来我运气很好。文件系统成功修复。

其实对于这种superblock破坏很严重的文件系统,其实系统已经有了很强大的修复方案:

我们可以用mke2fs -S 来修复superblock

[root@dhcp-0-175 /]# mount /dev/sdb1 /mnt/

mount: you must specify the filesystem type

[root@dhcp-0-175 /]# mount /dev/sdb1 /mnt/ -t ext3

mount: wrong fs type, bad option, bad superblock on /dev/sdb1,

missing codepage or other error

In some cases useful info is found in syslog – try

dmesg | tail or so

[root@dhcp-0-175 /]# mke2fs -S /dev/sdb1

mke2fs 1.39 (29-May-2006)

Filesystem label=

OS type: Linux

Block size=1024 (log=0)

Fragment size=1024 (log=0)

24480 inodes, 97656 blocks

4882 blocks (5.00%) reserved for the super user

First data block=1

Maximum filesystem blocks=67371008

12 block groups

8192 blocks per group, 8192 fragments per group

2040 inodes per group

Superblock backups stored on blocks:

8193, 24577, 40961, 57345, 73729

Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 37 mounts or

180 days, whichever comes first. Use tune2fs -c or -i to override.

[root@dhcp-0-175 /]# mount /dev/sdb1 /mnt/

[root@dhcp-0-175 /]# cd /mnt

[root@dhcp-0-175 mnt]# ls

file0 file14 file20 file27 file33 file4 file46 file52 file59 file65 file71 file78 file84 file90 file97

file1 file15 file21 file28 file34 file40 file47 file53 file6 file66 file72 file79 file85 file91 file98

file10 file16 file22 file29 file35 file41 file48 file54 file60 file67 file73 file8 file86 file92 file99

file100 file17 file23 file3 file36 file42 file49 file55 file61 file68 file74 file80 file87 file93 lost+found

file11 file18 file24 file30 file37 file43 file5 file56 file62 file69 file75 file81 file88 file94

file12 file19 file25 file31 file38 file44 file50 file57 file63 file7 file76 file82 file89 file95

file13 file2 file26 file32 file39 file45 file51 file58 file64 file70 file77 file83 file9 file96

[root@dhcp-0-175 mnt]#

e2fsck也可以达到同样的效果

[root@dhcp-0-175 /]# mount /dev/sdb1 /mnt/ -t ext3

mount: wrong fs type, bad option, bad superblock on /dev/sdb1,

missing codepage or other error

In some cases useful info is found in syslog – try

dmesg | tail or so

[root@dhcp-0-175 /]# e2fsck /dev/sdb1

e2fsck 1.39 (29-May-2006)

Couldn’t find ext2 superblock, trying backup blocks…

/dev/sdb1 was not cleanly unmounted, check forced.

Pass 1: Checking inodes, blocks, and sizes

Pass 2: Checking directory structure

Pass 3: Checking directory connectivity

Pass 4: Checking reference counts

Pass 5: Checking group summary information

Free blocks count wrong for group #0 (3549, counted=3547).

Fix<y>? yes

Free blocks count wrong (88895, counted=88893).

Fix<y>? yes

Free inodes count wrong for group #0 (2029, counted=1929).

Fix<y>? yes

Free inodes count wrong (24469, counted=24369).

Fix<y>? yes

/dev/sdb1: ***** FILE SYSTEM WAS MODIFIED *****

/dev/sdb1: 111/24480 files (1.8% non-contiguous), 8763/97656 blocks

[root@dhcp-0-175 /]# mount /dev/sdb1 /mnt/ -t ext3

[root@dhcp-0-175 /]# ls /mnt

file0 file15 file21 file28 file34 file40 file47 file53 file6 file66 file72 file79 file85 file91 file98

file1 file16 file22 file29 file35 file41 file48 file54 file60 file67 file73 file8 file86 file92 file99

file10 file17 file23 file3 file36 file42 file49 file55 file61 file68 file74 file80 file87 file93 lost+found

file11 file18 file24 file30 file37 file43 file5 file56 file62 file69 file75 file81 file88 file94

file12 file19 file25 file31 file38 file44 file50 file57 file63 file7 file76 file82 file89 file95

file13 file2 file26 file32 file39 file45 file51 file58 file64 file70 file77 file83 file9 file96

file14 file20 file27 file33 file4 file46 file52 file59 file65 file71 file78 file84 file90 file97

[root@dhcp-0-175 /]#

Read-only file system错误的应急解决办法【转】

操作系统:redhat linux as 4.7

故障现象
: 一次看似正常的reboot后,登录时start log进程长时间停顿,大约十分钟后才进入到登陆界面,用root账号登陆后发现,整个系统变成了 Read-only file system,所有文件、文件夹均没有写权限,进而导致lamp环境彻底无法使用,甚至网络连接都无法启用。

应急措施
chmod 666 /dev/null
mount -o remount,rw /

以上2条命令可临时消除故障情况,实现服务器应急启动。

具体故障原因我也不确定。

Nginx下绑定自己签发的免费SSL数字安全证书【转】

由于HTTP协议明文传输数据,使得嗅探无处不在,因此对某些网站如购物交易类、注册登陆类等,需要开启HTTPS协议来增加安全性,保证用户的密码不被盗取和嗅探。

HTTPS需要SSL数字安全证书的支持,一般找浏览器信任的CA机构签发数字证书都是要收费的,价格一般在13美元/年至50美元/年不等。(除了StartSSL和PositiveSSL)

如果证书只是给自己用的,防止在线管理时密码被窃听,则可以自行颁发免费的SSL数字安全证书。
Debian5 + OpenSSL + Nginx环境步骤如下:

一、使用OpenSSL生成SSL数字安全证书

openssl genrsa -out privkey.pem 2048
openssl req -new -x509 -key privkey.pem -out cacert.pem -days 1095

上述命令中第一步是生成用户证书 RSA 密钥对,且不带密码。 第二步是证书请求生成和自签名,此时会要求输入参数,随便填,但Common Name必须填即将使用HTTPS的站点名称,比如:*.yourdomain.com 。

二、确保Nginx支持OpenSSL模块

Nginx默认是不支持SSL的,需要重新配置和编译,命令如下:

wget http://nginx.org/download/nginx-0.7.65.tar.gz
tar zxvf nginx-0.7.65.tar.gz
cd /root/nginx-0.7.65
./configure --with-http_stub_status_module --with-http_ssl_module
make
mv /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx.old
cp ./objs/nginx /usr/local/nginx/sbin/nginx
kill -USR2 `cat /usr/local/nginx/logs/nginx.pid`
kill -QUIT `cat /usr/local/nginx/logs/nginx.pid.oldbin`

上述命令其实也是一次标准的Nginx升级操作,其中的目录需要用户根据具体情况自行更改。
另外,用户也可以在编译前注释掉 auto/cc/gcc 中的 CFLAGS=”$CFLAGS -g” 这行,使Nginx不以Debug模式编译,节约文件和内存占用、提高速度。

三、修改Nginx配置

修改nginx.conf中相应的server段:

 server
{
listen 443;
ssl on;
ssl_certificate /etc/ssl/cacert.pem;
ssl_certificate_key /etc/ssl/privkey.pem;
server_name www.yourdoamin.com;
index index.html index.htm index.php;
root  /home/wwwroot/yourdomain;
......
......
}

其中SSL数字证书路径和域名路径也应根据实际情况修改。

四、重启Nginx

上传nginx.conf后,测试配置文件是否正确,并重启Nginx:

/usr/local/nginx/sbin/nginx -t
kill -HUP `cat /usr/local/nginx/logs/nginx.pid`

五、使用HTTPS协议访问网站

键入https://www.yourdomain.com 会出现警告框:
ssl-cert-security-warning
由于是自己使用,点击查看证书-安装证书,下次就不会再弹出该警报框。

至此,你就可以使用HTTPS协议安全的访问网站,不用担心用户名和密码会在传输过程中被嗅探、盗取。

编译php 5.3.6 出错:make: *** [sapi/fpm/php-fpm] Error 1

在编译php 5.3.6 时会遇到undefined reference to `libiconv_open‘的编译错误,以下是几种解决方法:

一、重新安装libiconv
wget http://ftp.gnu.org/pub/gnu/libiconv/libiconv-1.13.1.tar.gz
tar -zxvf libiconv-1.13.1.tar.gz cd libiconv- 1.13.1 ./configure
make
make install

二、去除 iconv模块再编译应用:
使用./configure –help查看参数,看具体应用如何去除iconv编译,例如下面是 opencc 的无 iconv的编译方法: opencc: ./configure CFLAGS=-liconv 再如php编译时,可在make时通过zend扩展参数去除libiconv的编译选项 make ZEND_EXTRA_LIBS=’-liconv’ make install

三、iconv重复安装在不同目录,造成include文件iconv.h等重复 通过 find / -name “iconv.h” 如果查找到2个以上返回结果,说明 iconv重复安装了,卸载多余的版本即可正常编译。

本人用第三种方法,确实有不同的版本,

删除一个就OK。

将一般的用户加入sudo组is not in the sudoers file. This incident will be reported解决方法

$whereis sudoers -------找出文件所在的位置,默认都是/etc/sudoers
有时候我们只需要执行一条root权限的命令也要su到root,是不是有些不方便?这时可以用sudo代替。默认新建的用户不在sudo组,需要编辑/etc/sudoers文件将用户加入,该文件只能使用visudo命令,
1) 首先需要切换到root, su – (注意有- ,这和su是不同的,在用命令”su”的时候只是切换到root,但没有把root的环境变量传过去,还是当前用乎的环境变量,用”su -“命令将环境变量也一起带过去,就象和root登录一样)
2) 然后 visudo 或者 vim /etc/sudoers, visudo 这个和vi的用法一样,由于可能会有人不太熟悉vi,所以简要说一下步骤
移动光标,到一行root ALL=(ALL) ALL的下一行,按i,插入模式,输入
your_user_name ALL=(ALL) ALL
然后按Esc,
输入“:”
再输入:wq
保存退出
这样就把自己加入了sudo组,可以使用sudo命令了。
3) 默认5分钟后刚才输入的sodo密码过期,下次sudo需要重新输入密码,如果觉得在sudo的时候输入密码麻烦,把刚才的输入换成如下内容即可:
your_user_name ALL=(ALL) NOPASSWD: ALL

Linux 对文件进行加锁/解锁

加锁:chattr +i /path/filename

解锁:chattr -i /path/filename

Redis安装配置

http://bbs.linuxtone.org/thread-7129-1-1.html

Redis介绍

Redis本质上一个Key/Value数据库,与Memcached类似的NoSQL型数据库,但是他的数据可以持久化的保存在磁盘上,解决了服 务重启后数据不丢失的问题,他的值可以是string(字符串)、list(列表)、sets(集合)或者是ordered   sets(被排序的集 合),所有的数据类型都具有push/pop、add/remove、执行服务端的并集、交集、两个sets集中的差别等等操作,这些操作都是具有原子性 的,Redis还支持各种不同的排序能力
Redis 2.0更是增加了很多新特性,如:提升了性能、增加了新的数据类型、更少的利用内存(AOF和VM)
Redis支持绝大部分主流的开发语言,如:C、Java、C#、PHP、Perl、Python、Lua、Erlang、Ruby等等

Redis性能:
根据Redis官方的测试结果:在50个并发的情况下请求10w次,写的速度是110000次/s,读的速度是81000次/s
测试环境:
1.        50个并发,请求100000次
2.        读和写大小为256bytes的字符串
3.        Linux2.6 Xeon X3320 2.5GHz的服务器上
4.        通过本机的loopback interface接口上执行
地址:http://code.google.com/p/redis/wiki/Benchmarks

Redis的功能:
1、Redis的Sharding:Redis支持客户端的Sharding功能,通过一致性hash算法实现,当前Redis不支持故障冗余,在集群中不能在线增加或删除Redis
2、Redis的master/slave复制:
1.        一个master支持多个slave
2.        Slave可以接受其他slave的连接来替代他连接master
3.        复制在master是非阻塞的,而在slave是阻塞的
4.        复制被利用来提供可扩展性,在slave端只提供查询功能及数据的冗余
3、Redis的Virtual Memory功能:vm是Redis2.0新增的一个非常稳定和可靠的功能,
vm的引入是为了提高Redis的性能,也就是把很少使用的value保存到disk,而key保存在内存中。实际上就是如果你有10w的keys在内存 中,而只有仅仅10%左右的key经常使用,那么Redis可以通过开启VM尝试将不经常使用的Value转换到disk上保存
4、Redis的附加档案(AOF)功能:Redis通过配置的策略将数据集保存到aof中,当Redis挂掉后能够通过aof恢复到挂掉前的状态

Redis的安装及配置:
下载Redis:wget http://redis.googlecode.com/files/redis-2.0.0-rc4.tar.gz

[[email protected]   ~/src]$ tar xvzf redis-2.0.0-rc4.tar.gz
[[email protected]   ~/src]$ cd   redis-2.0.0-rc4
[[email protected]   ~/src/redis-2.0.0-rc4]$ make
[[email protected]   ~/src/redis-2.0.0-rc4]$ mkdir ~/redis-2.0.0
[[email protected]   ~/src/redis-2.0.0-rc4]$cp redis-server   ~/redis-2.0.0
[[email protected]   ~/src/redis-2.0.0-rc4]$cp redis-benchmark   ~/redis-2.0.0
[[email protected]   ~/src/redis-2.0.0-rc4]$cp redis-cli   ~/redis-2.0.0
[[email protected]   ~/src/redis-2.0.0-rc4]$cp redis.conf   ~/redis-2.0.0
[[email protected]   ~/src/redis-2.0.0-rc4]$ cd ~/redis-2.0.0/

复制代码

配置redis.conf配置文件:

#是否作为守护进程运行
daemonize yes
#配置pid的存放路径及文件名,默认为当前路径下
pidfile redis.pid
#Redis默认监听端口
port 6379
#客户端闲置多少秒后,断开连接
timeout 300
#日志显示级别
loglevel verbose
#指定日志输出的文件名,也可指定到标准输出端口
logfile stdout
#设置数据库的数量,默认连接的数据库是0,可以通过select N来连接不同的数据库
databases 16
#保存数据到disk的策略
#当有一条Keys数据被改变是,900秒刷新到disk一次
save 900 1
#当有10条Keys数据被改变时,300秒刷新到disk一次
save 300 10
#当有1w条keys数据被改变时,60秒刷新到disk一次
save 60 10000
#当dump   .rdb数据库的时候是否压缩数据对象
rdbcompression yes
#dump数据库的数据保存的文件名
dbfilename dump.rdb
#Redis的工作目录
dir /home/falcon/redis-2.0.0/
###########   Replication #####################
#Redis的复制配置
# slaveof <masterip> <masterport>
# masterauth <master-password>############## SECURITY ###########
# requirepass foobared

############### LIMITS ##############
#最大客户端连接数
# maxclients 128
#最大内存使用率
# maxmemory <bytes>

########## APPEND ONLY MODE #########
#是否开启日志功能
appendonly no
# 刷新日志到disk的规则
# appendfsync always
appendfsync everysec
# appendfsync no
################ VIRTUAL MEMORY ###########
#是否开启VM功能
vm-enabled no
# vm-enabled yes
vm-swap-file logs/redis.swap
vm-max-memory 0
vm-page-size 32
vm-pages 134217728
vm-max-threads 4
############# ADVANCED CONFIG ###############
glueoutputbuf yes
hash-max-zipmap-entries 64
hash-max-zipmap-value 512
#是否重置Hash表
activerehashing yes

复制代码

启动Redis

[[email protected]   ~/redis-2.0.0]$ ./redis-server redis.conf
检测Redis是否启动:
[[email protected]   ~/redis-2.0.0]$ netstat -an -t
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address             Foreign Address          State
tcp        0    0 0.0.0.0:10022             0.0.0.0:*                LISTEN
tcp        0    0 0.0.0.0:6379             0.0.0.0:*                LISTEN
……..
[[email protected]   ~/redis-2.0.0]$ ps -ef|grep redis-server
falcon 7663     1   0 02:29 ?        00:00:00 ./redis-server redis.conf