HANIX
Hanix aims at Apps of uNIX
最新日志 
3rd-Mar-2012 02:36 pm - opkg软件包制作相关
opkg软件包的制作,网上中文相关的资料不多。在网上找到两篇,读了后大致了解opkg软件包的制作。
在inporttb上的一篇写的比较详细:http://inportb.com/2010/10/19/making-an-opkg-package/
另外在opkg的svn仓库中也有相关:
http://svn.openmoko.org/trunk/src/host/opkg-utils

不过看svn的更新都是09年时候的了。

另外可以借鉴debian包的制作,两者非常相近,相比redhat的rpm包管理也优雅很多。

下面的文章转自inporttb:

Now that we have Opkg for Android, we could use it to install packages from local files or off Web servers. Installing a package is as simple as

opkg install path/to/package.opk

or, if it’s on the Web

opkg install http://host/path/to/package.opk

And to remove the package, we would go

opkg remove name-of-package

But what if we wanted to share our own software with others? In this case, we would create our own packages. An Opkg package is essentially a Debian package with fewer control fields. If you know how to make a Debian package, you should be well on your way. In general, a package is an ar archive containing a control tarball, a data tarball, and a debian-binary file. For example let’s have a look at the opkg-hello package:

package.opk (ar)
+- debian-binary (text)
+- control.tar.gz (tarball)
...+- control (text)
...+- preinst (script)
...+- postinst (script)
...+- prerm (script)
...+- postrm (script)
+- data.tar.gz (tarball)
...+- system
......+- bin
.........+- opkg-hello (example program)

Now, debian-binary simply contains the string 2.0; it signifies that the archive is indeed a Debian[esque] package. The files within control.tar.gz are cached when the package is installed, and contain information about the package itself, how the package is to be installed, and how the package is to be removed. The contents of control describe the package and are used to build the repository feed, which we will cover later. There are also scripts that govern the installation and removal processes and require execution permission: preinst runs before the package is extracted, postinst performs any configuration after the main files are in place, prerm prepares the system before the package is removed, andpostrm cleans up after the main files are gone. Let’s have a look inside these files:

control
Package: opkg-hello
Version: 0.0.1
Description: Sample OPKG package
Section: cyanogenmod/applications
Priority: optional
Maintainer: Jiang Yio
Architecture: all
Homepage: http://inportb.com/
Source:
Depends:

preinst
#!/system/bin/sh
echo "preinst: preparing to install package"
mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system

postinst
#!/system/bin/sh
mount -o ro,remount -t yaffs2 /dev/block/mtdblock3 /system
echo "postinst: installed package"

prerm
#!/system/bin/sh
echo "prerm: preparing to remove package"
mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system

postrm
#!/system/bin/sh
mount -o ro,remount -t yaffs2 /dev/block/mtdblock3 /system
echo "postrm: removed package"

Other than emitting some debugging information, the scripts also make the/system tree writable while the package is installed or removed.

Now that we have the anatomy of an Opkg package, we could create more like it with ease. Here are a couple of helpful commands:

make a tarball
tar zcvf name-of-tarball.tar.gz list of files and directories

make an archive
ar -r name-of-archive.opk list of files and directories

Other than that, just be sure all the files have the right owner, group, and permission. It would also help to know something about the Android directory tree — for example, we dropped the example program in /system/bin, which we know is part of the search path.


8th-Apr-2010 09:21 am - linux下键盘映射
家里的笔记本,左右2个shift键都被我女儿搞坏了,sigh

换一个笔记本键盘还是挺麻烦的一件事,所以我就想用键盘映射解决。

目前linux下解决键盘映射的方法有:
1、xmodmap
2、setxkbmap

我采用了xmodmap方法来解决。

首先用Caps_Lock代替Shift_L,用Control_R代替Shift_R,Caps_Lock的使用不多,而且也并非必须,右边的Control平时根本用不上。

在Home目录下编辑.xmodmaprc

remove Lock = Caps_Lock
remove Shift = Shift_L
keysym Shift_L = Caps_Lock
keysym Caps_Lock = Shift_L
# add Lock = Caps_Lock
add Shift = Shift_L

remove Control = Control_R
remove Shift = Shift_R
keysym Control_R = Shift_R
keysym Shift_R = Control_R
# add Control = Control_R
add Shift = Shift_R

使用xmodmap需要理解3个概念:
modifier,keysym, keycode

keycode是键码,在键盘上的位置固定了,那么键码也就定了。
keysym,keysym是表示功能的,一个键码可以表示多个keysym,就是说一个键可以有多个功能。
modifier,修饰符:shift,lock,control,mod1-5,每个修饰符,可以包含多个keysym.

xmodmap的常见操作有:
keycode NUMBER = KEYSYMNAME ...当我们想增加某个键的功能时,使用它。
keysym KEYSYMNAME = KEYSYMNAME ...左边keysym对应的键码,其keysym全部设置为右边的keysym。如果右边的keysym列表中没有出现左边的keysym,那么xmodmap -pk|grep left_keysym将找不到任何原来的keysym.

另外如果使用keysym交换2个key的用途(如上面例子所示),那么需要注意不能在命令行下分开执行,必须在同一命令下执行,即:xmodmap -e 'keysym a = b' -e 'keysym b = a'。如果将keysym分2次执行,则得不到效果。
clear MODIFIERNAME删除该修饰符下所有的keysym
add MODIFIERNAME = KEYSYMNAME ...在某个修饰符下添加keysym
remove MODIFIERNAME = KEYSYMNAME ...删除某修饰符下的具体的keysym

15th-Sep-2009 11:50 am - kvm中的base_image妙用
转载自http://www.linux-kvm.com/content/be-more-productive-base-images-part-1[23]

There are some useful ways in which you can use qemu base images to build template virtual machines. If used wisely you can save yourself from ever having to install the same OS more than once. The main thing that you should be aware of when using base images is the dependency between images but once managed properly, you can save yourself a lot of time.


Qemu/KVM base images

Base imaging was inherited from the qemu userspace component as an added feature of kvm. The idea behind the base image is simple. You build a disk image as you would build a normal image. You then build a new image using the first image as your base image, also known as the backing file. From this point on, kvm will only read from your base image (backing file). If anything needs to be written to your image, kvm will only write to the new image. It is, in effect, similar to a diff where all new data is written only to the new image while preserving the state of your backing file. As a sideffect, your working image will be the same size as your base image. This is where the qemu copy on write term came from.


Building your base image

Your base image should be based on a template disk image that is a practical starting point for your needs. Personally I like to start with a base image that is at a state right after a fresh install; no patches, no applications, just the state of the machine right after installation and registration of the OS if it requires registration. You would start by using the usual qemu-img command as you normally would for creating your base image. For example, to install your base image for a windows xp base image you would create the image with the following command.

qemu-img create -f qcow2 windows-master.qcow2 10G

This image will be your base image. Once your image is created you boot the image and install the OS as you normally would with a command similar to the following:

qemu-system-x86_64 -hda windows-master.qcow2 -m 512 -boot d -cdrom /home/user/isos/en_winxp_pro_with_sp2.iso

Install your OS to completion and back up this image immediately. This is your new base image and you will not have to ever boot this image in life again.


Create a new image from your template base image

Now that you have your base image you are ready to install a new image from this template. You would create your new image with the following command using the –b flag.

qemu-img create -b windows-master.qcow2 -f qcow2 windows-clone.qcow2

This will create a new copy-on-write image called windows-clone.qcow2 which uses your original windows-master as your template base image. You don’t need to specify a filesize with this command as it will automatically set your new image to the same size as your base image. At this point run the following command on your new image and note the size of your new image.

# qemu-img info windows-clone.qcow2

image: windows-clone.qcow2
file format: qcow2
virtual size: 10G (10737418240 bytes)
disk size: 56K
cluster_size: 4096
backing file: windows-master.qcow2 (actual path: windows-master.qcow2)

Note the size of your new image is 10G , the size of your original base image and note how small your image is, 56 k. At this point, your new image is basically a clone of your base image and dependent on your base image being in the same state it was at the time your clone was created. For this reason, you should try to never boot your base image again as some data may be inadvertently be written to disk causing some inconsistencies. Boot up your new clone image with a command similar to the following

qemu-system-x86_64 -hda windows-clone.qcow2 -m 400

You new clone will boot up and you will see that it is a perfect clone of your original base image. As you install patches, applications and write data to your new image you can see it growing in size but your base image will always remain unchanged from it’s original state. You can use the qemu-img command to verify this. Try installing some applications on your new clone then run the following commands on both your base image and your new clone.

# qemu-img info windows-master.qcow2
# qemu-img info windows-clone.qcow2

You will see that your clone image is growing and your base image has remained the same size.


What next?

Using base images , you should never have to install your operating systems again after the first install. Perform your experiments on your new clone; if something goes wrong, simply delete your clone and recreate another clone. You can also have multiple clones running off of one base image without any problems.

Now that you know how to build a base image and images hanging off of your base image, the next thing that you will want to do is “rebasing” your images. For the next post in this series, I’ll walk through how you can rebase your new image to build new up to date base images for cloning.



In the first part of this series about using base images to be more productive, I discussed how you can use base images to build template disk images from which you can create copy on write clones. As a natural follow up to creating your clones, at some point you’ll want to update your base images with patches or applications that is a better starting point for a clone. Regardless of how well you planned your base images, you may find that you need to update your base images to minimize additional installation on your clones. You can achieve this by “rebasing” your disk images.


What is Rebasing?

Simply put, rebasing is the process of merging your current clone with your base image to create a new base image file that is completely different and independent from your original base image. You new base image will not have any dependency on your original base image and can be used for creating new clones. I think it’s good idea to always keep a base image with a pure install and additional rebased images for different purposes. For example, in a desktop environment one rebased image can be used for marketing department, another for customer service etc all built by merging different clones with an original single install base image. Rebasing can save you loads of time.


Creating your first rebased image

Now that you understand what a rebased image is, let’s create one. I’ll use the same image names from the first part of the series for continuity. In order to rebase your image you only need to issue one single command. The command follows.

qemu-img convert windows-clone.qcow2 –O qcow2 windows-marketing.qcow2

That’s it. Your windows-marketing.qcow2 will be a new base image completely independent from the original base image (windows-master.qcow2) used to create windows-clone.qcow2. It will be a merge of the windows-clone.qcow2 and the original windows-master.qcow2 images from the original post. This means that even if you destroy your windows-master.qcow2, your new rebased image will not be affected since there’s no dependency.


Summary

You now know what a rebased image is and how to create one. It only involves running a single command. Rebasing images can save you time by allowing you to create repurposed base images that you can use to deploy quickly and easily. In the next and last part of the series , I’ll explore another option recently added to qemu-img and how it might be used.



There’s a lesser known option that was added fairly recently to kvm-71 as an addition to the qemu-img command. It allows you to create a copy on write image while using the convert option. This option will probably not be as useful as basing images and rebasing images but it should at least be an option that you’re aware of. It’s a new b argument for creating copy on write images from base images while converting formats.


The syntax

The syntax for the new argument when using the convert parameter with qemu-img is as follows:

qemu-img convert -O qcow2 -B master-windows2003-base.qcow2 master-windows2003.qcow2 final.qcow2

Note the –B argument which tells qemu-img that the newly created image (final.qcow2) will be a copy on write image of the specified base image (master-windows2003-base.qcow2). What you’re basically saying is convert master-windows2003.qcow2 to final.qcow2 and let this converted image be a copy on write of the image specified by the –B argument. This essentially means that the master-windows2003.qcow2 and master-windows2003-base.qcow2 should have the same content but they may differ in location, format etc.


If you do a qemu-img info you’re your final.qcow2 image, it looks like the following.

qemu-img info final.qcow2

image: final.qcow2
file format: qcow2
virtual size: 10G (10737418240 bytes)
disk size: 1.2G
cluster_size: 4096
backing file: master-windows2003-base.qcow2 (actual path: master-windows2003-base.qcow2)

Note that unlike copy on write images as described previously, these copy on write images are actually the same size as the backing file and actually take some time to convert.


Summary

This concludes the short series on base images. In Part 1 and Part 2 of this series you’ve seen how to create images from base templates and rebasing your disk images. In this post, you’ve seen the new optional argument for the qemu-img command and how it might be used. You’ll probably not find yourself using this option very much but I think it’s always good to know your options. Personally, I can’t think of how I might use this option very much as it doesn’t really save much disk space or time and in that case I would probably opt for just a straight conversion. In any case now you know.
由于web代码部署,在服务器端的实现相对仍然是比较复杂的,说复杂是由于下面几个原
1、web服务器如果较多,代码的分发需要采用异步方式
2、异步的话,如何通知用户代码‘真正’的部署成功了
3、如果有web服务器部署失败,那么用户的代码实际上处于不一致状态,如何回滚

这些问题如果都亲自实现,实现的复杂度还是比较高的,而且没那么好实现,特别是代码的回滚。在分布式环境中,一致性问题是一直比较艰巨。

所以有了用nfs服务器保存web代码的想法。

nfs的优点
1、服务稳定,nfs协议经过了若干年的发展,非常可靠
2、服务端的io如果高,会引发nfs客户端大量阻塞,进而造成大面积宕机
3、有时候nfs客户端到服务器端的网络如果抖动,也都会造成很严重的后果。

基于上述原因,一般在存储解决方案中,对于大型网站,一般都尽量避免nfs的挂载。

fs-cache/cachefs
如果在客户端能够大量缓存服务器端的文件,那么读压力就可以消除了。代码的部署实际上写压力并不大,只要很好地控制好,该方案还是可行的。

实验
服务器端:
/etc/init.d/portmap start
/etc/init.d/nfs start
/etc/init.d/rpcidmapd start

[root@vm0000154 vol2]# cat /etc/idmapd.conf
[General]

Verbosity = 0
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = localdomain

[Mapping]

Nobody-User = nobody
Nobody-Group = nobody

[Translation]
Method = nsswitch

[root@vm0000154 vol2]# cat /etc/exports

/data1/nfs4 10.0.0.0/8(rw,fsid=0,insecure,no_subtree_check,sync,anonuid=99,anongid=99)

客户端:
内核中需要nfs需要支持fscache
CONFIG_FSCACHE=m
CONFIG_FSCACHE_STATS=y
CONFIG_FSCACHE_HISTOGRAM=y
CONFIG_FSCACHE_DEBUG=y
CONFIG_CACHEFILES=m
CONFIG_CACHEFILES_DEBUG=y
CONFIG_CACHEFILES_HISTOGRAM=y
CONFIG_NFS_FSCACHE=y
CONFIG_AFS_FSCACHE=y

安装cachefilesd程序
http://people.redhat.com/~dhowells/fscache/cachefilesd-0.9.tar.bz2

# cat /etc/cachefilesd.conf
dir /var/cache/fscache
tag mycache
brun 10%
bcull 7%
bstop 3%
frun 10%
fcull 7%
fstop 3%

启动cachefilesd
#/sbin/cachefilesd

fscache 需要user_xattr属性支持
#mount -o remount,rw,user_xattr /var

挂载nfs4服务
#mount -t nfs4 -o fsc,rw,intr 10.210.141.160:/vol2 /mnt/nfs4
10th-Jul-2007 04:06 pm - 庆祝lj可以访问
好久不来这里了。


LJ终于可以访问了,自己发帖庆祝一下。
20th-Apr-2007 04:23 pm - 系统负载奇怪升高 [loadavg]
这两天,系统的负载一直在30左右,但是查看了cpu,内存,io,网络,负载都非常的轻。到底什么原因?

用ps ax查看,发现系统中有许多处于D+状态的sendmail进程,这些进程都处于不可中断的状态。数了一下,大致也在30个左右。

再分析sendmail进程为什么会处于D+状态?

到/var/spool/目录下,发现clientmqueue和mqueue下有大量的小文件,这个时候只要有进程作用于这两个目录,都有可能导致不可中断(D+),包括rm命令。


系统负载的计算方法:
过去1m/5m/15m时间内,平均等待的进程数。

所以有多少个D+状态的进程,系统负载就会升到多少。
12th-Apr-2007 04:22 pm - linux做nat网关 [gateway, iptables, nat]
echo 1 > /proc/sys/net/ipv4/ip_forward
/sbin/rmmod ipchains
/sbin/modprobe ip_tables
/sbin/modprobe iptable_filter
/sbin/modprobe iptable_nat
/sbin/modprobe ip_conntrack
/sbin/modprobe ip_conntrack_ftp
/sbin/modprboe ip_nat_ftp
/sbin/iptables -F INPUT
/sbin/iptables -F FORWARD
/sbin/iptables -F POSTROUTING -t nat
/sbin/iptables -P FORWARD DROP
/sbin/iptables -t nat -A POSTROUTING -o eth0 -s 192.168.8.0/24 -j MASQUERADE
/sbin/iptables -A FORWARD -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
/sbin/iptables -A FORWARD -s 192.168.8.0/24 -j ACCEPT
11th-Apr-2007 01:51 pm - Linux下在vmware中添加新的vmnet
在Linux 下,有时为了做一些网络方面的测试,就需要启用多个网段进行实验。
默认情况下,vmware提供了vmnet0/vmnet1/vmnet8,但是如果你想使用更多的网段,该怎么办?

方法其实很简单,就是修改/etc/vmware/locations文件,在文件开头:
answer NETWORKING yes
answer VNET_0_INTERFACE eth0
answer VNET_8_NAT yes
answer VNET_8_HOSTONLY_HOSTADDR 192.168.63.1
answer VNET_8_HOSTONLY_NETMASK 255.255.255.0
answer VNET_1_HOSTONLY_HOSTADDR 192.168.95.1
answer VNET_1_HOSTONLY_NETMASK 255.255.255.0

添加其他的vmnet。如果需要nat服务,就定义成 answer VMNET_9_nat yes,如果不需要nat,则直接添加:
answer VNET_2_HOSTONLY_HOSTADDR 192.168.64.1
answer VNET_2_HOSTONLY_NETMASK 255.255.255.0

/etc/init.d/vmware restart
后,就能发现/dev/vmnet2已经存在了,并且
ifconfig后
也能发现新的vmnet2接口了。
9th-Apr-2007 06:23 pm - openVPN配置
一、内核驱动
tun/tap支持。
Device Drivers->Network device support->Universal TUN/TAP device driver support
IP forward support/enable routing:
echo 1 > /proc/sys/net/ipv4/ip_forward
4th-Apr-2007 04:42 pm - kvm, xen, vmware
这三个虚拟机目前在一个linux内核下没法共存,只能用一个。

要都支持的话,就需要编译三个不同版本号的内核。

今天在2.6.20下编译vmware时,可以编译过去,但是插入模块时,报错:
vmmon: Unknown symbol paravirt_ops

查了一下,发现是CONFIG_PARAVIRT=y引起,但是kvm是需要它的。
This page was loaded May 27th 2012, 7:46 am GMT.