Linux
apt-cacher-ng: 万能软件包代理
4月20日
在 《Git权威指南》一书中,我在介绍 Cygwin 安装时,提到了如果整个团队在使用 Cygwin,最好架设一个代理服务器,这个代理服务器就好像一个本地软件包镜像,区别在于这个软件包镜像不是上游镜像的完整克隆,而是按需镜像。即第一次安装某个软件包时,代理服务器到上游获取然后缓存并发送给请求者,当再有用户请求同样的软件包时,直接从缓存中提取。架设这样的代理服务器,只需安装和配置 apt-cacher-ng 软件即可。
Apt-cacher-ng 本身就是一个 HTTP 协议代理,但是和其他 HTTP 代理服务器的区别在于:
- 能够“识别”出从不同站点(源)请求下载的软件包是否是同一个软件包,即源的合并功能。
- 支持请求重定向。即可以不直接从客户请求的地址下载,而是重定向到预先设定的可能更快的镜像进行下载。
Apt-cacher-ng 本来是服务于 Debian 和 Ubuntu,但是其通用性的设计,同样可以作为 Fedora, CentOS, Cygwin 等软件包代理。核心配置就是 Repomap 指令。
Remap-RepositoryName: MergingURLs ; TargetURLs
其中:
- RepositoryName 是本地的软件包镜像库(目录)的名称,该名称一旦确定不要变更。例如针对不同的系统软件包镜像,写为:debian, ubuntu, centos, 或 cygwin。
- MergingURLs 是用空格分割的 URL 地址或者匹配 URL 的字符串。当请求的软件包地址和这些地址匹配后,就认为是针对 RepositoryName 软件包镜像库的请求。
- 分号后面的 TargetURLs 也是用空格分割的 URL 地址。TargetURLs 是可选项,如果设置,则对该软件包镜像库的访问重定向由 TargetURLs 指定的地址。
Cygwin 的 Remap- 的设置:
Remap-cygwin: file:cygwin_mirrors.list /cygwin ; file:backends_cygwin
其中 file:cygwin_mirrors.list 所指向的文件包含所有 Cygwin 镜像(HTTP协议)地址,每个一行,这样就不至于让 Remap-cygwin 指令太长。该文件包含的地址有:
http://cygwinmirror.3gforphones.com/ http://cygwin.matway.net/ http://ftp.inf.tu-dresden.de/software/windows/cygwin32/ http://ftp.iitm.ac.in/cygwin/ ...
其中有的镜像是放在网站的 /cygwin/ 地址下,但也有地址是直接放在根下或者其他目录下。
文件 backends_cygwin 则设置为国内的 Cygwin 镜像。内容如下:
http://mirrors.163.com/cygwin/
配置 Apt-cacher-ng 作为 CentOS 软件包镜像和 Cygwin 类似,但需要多做一些工作。缺省的 apt-cacher-ng 只对特定的文件进行代理,包括 .deb, .rpm 文件,以及 Index, Packages.bz2, Release 等软件包索引文件等,而 CentOS 特有的软件包索引文件没有列在其中。
修改 /etc/apt-cacher-ng/acng.conf 配置文件,将 CentOS 的索引文件添加其中,下面示例中加粗内容即是为支持 CentOS 而新增内容:
VfilePattern = (^|.*?/)(Index|Packages\.bz2|Packages\.gz|Packages|Release|Release\.gpg|Sources\.bz2|Sources\.gz|Sources|release|index\.db-.*\.gz|Contents-[^/]*\.gz|pkglist[^/]*\.bz2|rclist[^/]*\.bz2|/meta-release[^/]*|Translation[^/]*\.bz2|repodata/.*|mirrorlist\?.*)$
搭建本地YUM软件仓库
4月12日
通过前面RPM打包的学习,我们了解了如何制作RPM软件包,然后就可以HLL地通过rpm命令安装了,但是,一个很严肃的问题是,rpm不支持解决安装依赖,如果你的软件包安装时需要依赖神马神马包的话,RPM会这样告诉你:
$ rpm -ivh ~/rpmbuild/RPMS/i386/hello-0.2-1.i386.rpm
error: Failed dependencies:
world is needed by hello-0.2-1.i386看,rpm说,我需要整个世界,这个包木有安装,这个包你有木有?有木有?
如果很幸运,你这里刚好有一个world包,赶紧安装:
$ rpm -ivh ~/rpmbuild/RPMS/i386/world-0.1-1.i386.rpm
error: Failed dependencies:
freedom is needed by world-0.1-1.i386看来这个世界缺少自由呀,不行,还得寻找自由。。。怎么这么麻烦?有没有更好的解决方法?
你可能想到yum了。对,yum就是为解决依赖而生的,如果说redhat的rpm就像debian里的dpkg的话,那么yum就像aptitude了。
通过yum安装yum软件仓库里的软件包,它会自动解决软件安装依赖,一条命令就全部解决。
但,如果俺们的软件包并未在yum软件仓库里咋办呢?那么,咱家就自己搭建一个yum仓库吧~
在搭建yum软件仓库之前,先了解一下yum源的配置吧。
YUM源探秘
centos中yum的主配置文件在/etc/yum.conf中,粘贴如下:
[main] cachedir=/var/cache/yum keepcache=0 debuglevel=2 logfile=/var/log/yum.log distroverpkg=redhat-release tolerant=1 exactarch=1 obsoletes=1 gpgcheck=1 plugins=1 # Note: yum-RHN-plugin doesn't honor this. metadata_expire=1h # Default. # installonly_limit = 3 # PUT YOUR REPOS HERE OR IN separate files named file.repo # in /etc/yum.repos.d
这又是一个INI文件。第一行的cachedir定义了缓存的目录,最后一行说的就是可以把自己的软件仓库放在这个文件里或者以repo为后缀名放在/etc/yum.repos.d目录下。
为了方便起见,最好将配置文件存放在yum.repos.d目录下,而不是修改这个文件。
在软件源列表目录/etc/yum.repo.d/下,其中有一个是必须且唯一的,就是Base源文件。
- 源文件是ini格式的。大致结构如下: ::
- [server-id]
name=
mirrorlist=
baseurl=
gpgcheck= 0,不检查,1,检查
enabled= 0,禁用,1,启用
server-id,指代软件库服务器id,在生成缓存时会生成对应的目录。如果是我们自己写的配置文件,这个地方可以任意,但注意看CentOS-Base.repo文件,这个是yum软件仓库的主要配置文件,有base,updates,addons,extras,centosplus,contrib这几个章节,这是不能随意修改的,这就是传说中的Base文件。
mirrorlist和baseurl两者使用一个即可,一般大型的官网,比如centos,fedora-epel会使用mirrorlist形式的,通过传递参数,自动选择最快的源,而对于咱们自己搭建的源来说,使用baseurl即可。
上面会使用几个变量:
- $releasever 发行版版本,如5.5
- $arch CPU体系,如i686,i386,x86_64等
- $basearch CPU基础体系,如i386,x86_64,ppc
官方的源比较慢,我们可以修改使用国内的源,比如163的,sohu的等,具体可以去mirrors.163.com和mirrors.sohu.com查看。
再到/var/cache/yum目录下,可以看到有很多子目录,这些和上面的章节名一一对应,如base,addons,contrib等。
此外,还有一个timedhost.txt文件,这个文件记录了各个软件源仓库的链接速度。
其实这个文件是由yum的一个插件yum-fastestmirror生成的,默认的yum貌似安装了这个插件:
$ yum list yum-fastestmirror yum-fastestmirror.noarch 1.1.16-14.el5.centos.1 installed
如果没有的话,直接在官方源里安装:
$ sudo yum install yum-fastestmirror
使用clean命令清理所有缓存:
$ sudo yum clean all
这下缓存目录里的文件都被删除了,只剩下各个文件夹。执行makecache命令生成缓存::
$ sudo yum makecache
使用check-update也会生成缓存:
$ sudo yum check-update
搭建本地源
工欲善其事,必先利其器。开始之前,我们需要找到一款合适的工具,这就是,createrepo,这个软件官方源里就有:
$ sudo yum install createrepo
安装完毕以后我们就可以行动了。
首先创建目录:
$ sudo mkdir -p /var/www/html/centos/5.5/{i386,x86_64,noarch,updates,SRPMS}这个目录结构是参照前面的repo文件和163,sohu等的centos仓库源目录结构写出来的。
接下来把自己的软件包分门别类,对号入座,放到上面各个目录下。然后,createrepo隆重出场:
$ cd /var/www/html/centos/5.5/
$ ls | xargs -i sudo createrepo {}这样,createrepo在每个目录下创建了repodata目录,里面存放的就是文件列表数据,从而可以被yum寻找到。
当目录下的RPM包更新以后,记得使用createrepo更新数据库文件:
$ ls | xargs -i sudo createrepo --update {}接下来需要编写一份我们自己的repo文件,参照系统中的例子,编写如下:
[ossxp] name=Extra Packages for Enterprise Linux 5 - $basearch baseurl=http://localhost/centos/5.5/$basearch failovermethod=priority enabled=1 gpgcheck=0 [ossxp-source] name=Extra Packages for Enterprise Linux 5 - $basearch - Source baseurl=http://localhost/centos/5.5/SRPMS failovermethod=priority enabled=0 gpgcheck=0
默认启用ossxp软件仓库,停用ossxp-source仓库,如果需要使用yumdonwloader在ossxp-source下载源代码,可以在命令行里启用:
$ sudo yumdownloader --enablerepo=ossxp-source --source hello
当然前提是启动了Apache服务器。
Linux下的通用打开命令
4月12日
在Mac下的终端里可以输入open来打开任意类型的文件,linux下是否也有类似的命令呢?
经查,发现有三个命令可以实现类似效果:
- see
see通过查找在mailcap文件中设定的文件类型和应用程序映射来打开文件。系统配置文件在/etc/mailcap,用户可以自定义配置文件到~/.mailcap。
通过see调用GUI程序以后要等待程序结束才可以继续输入命令。
- xdg-open
xdg-open使用的配置文件不详。调用程序后终端仍可继续输入命令而不必等待程序结束。
- gnome-open
gnome-open使用GNOME文件管理来打开文件。一般和Nautilus中设定的文件关联一致。
测试
我的系统为Ubuntu 11.04。
打开pdf文件,see调用了Okular打开,而xdg-open和gnome-open调用了evince。
打开jpeg文件,see调用了feh,而xdg-open和gnome-open调用了eye of gnome。
打开html文件,三者都调用了x-www-browser,这里是google-chrome。
打开utf-8编码的txt(后缀为txt),see调用了less,xdg-open和gnome-open调用了gedit。
打开utf-8编码的txt(无后缀),see不识别:
Warning: unknown mime-type for "test_utf-8" -- using "application/octet-stream"
Error: no "view" mailcap rules found for type "application/octet-stream"而xdg-open和gnome-open处乱不惊,gedit依旧。
打开cp936编码的txt,see误以为二进制文件,强制打开后失败,退出码1:
$ see test_gbk.txt
"/tmp/file1tdJGh" may be a binary file. See it anyway?
Warning: program returned non-zero exit code #1xdg-open和gnome-open表现的很淡定,继续gedit之。
总结
see的配置文件mailcap超级复杂,要自定义恐怕要费不少时间,而xdg-open/gnome-open由于和Nautilus保持一致,这样就很和谐,很方便。并且xdg-open/gnome-open在输入命令后不必等待程序结束就可以继续输入,比see要实用。
参考自:http://zh-cn.w3support.net/index.php?db=so&id=264395
RPM打包step by step(2)
4月8日
在源代码中打包
仍拿前面的helloworld举例,把spec文件放到开发目录下,修改去掉补丁文件,然后打包:
$ ls hello-0.2
hello.c hello.spec Makefile
$ tar zcvf hello-0.2.tar.gz hello-0.2
hello-0.2/
hello-0.2/Makefile
hello-0.2/hello.spec
hello-0.2/hello.c接下来就要用到rpmbuild另一个很有用的参数了:-t,可以看一个rpmbuild的man:
$ man rpmbuild
NAME
rpmbuild - Build RPM Package(s)
SYNOPSIS
BUILDING PACKAGES:
rpmbuild {-ba|-bb|-bp|-bc|-bi|-bl|-bs} [rpmbuild-options] SPECFILE ...
rpmbuild {-ta|-tb|-tp|-tc|-ti|-tl|-ts} [rpmbuild-options] TARBALL ...
rpmbuild {--rebuild|--recompile} SOURCEPKG ...
MISCELLANEOUS:
rpmbuild --showrc
...rpmbuild通过-t参数来构建打包过的源程序。-ta就是构建rpm包和srpm包,-tb就是只构建二进制rpm包,-tp是只构建打过补丁的包,-ts是只构建srpm包。
好了,现在可以生成rpm包了:
$ rpmbuild -ta hello-0.2.tar.gz如果使用git的话,就更方便了,因为Git提供了对任意分支打包的命令:git-archive。下面我们先使用git初始化我们的开发目录,然后使用git-archive来生成压缩包。
$ cd hello-0.2
$ git init
Initialized empty Git repository in /home/admin/work/hello-0.2/.git/
$ git add -A
$ git ci -m init
3 files changed, 73 insertions(+), 0 deletions(-)
create mode 100644 Makefile
create mode 100644 hello.c
create mode 100644 hello.spec
$ git archive --prefix=hello-0.2/ master|gzip > hello-0.2.tar.gz
$ ls
hello-0.2.tar.gz hello.c hello.spec Makefile通过 –prefix参数使当前master分支下文件打包到hello-0.2目录下,注意在文件夹名后面一定要有一个斜扛,否则就变成一般的文件名前缀了。
生成压缩包以后,就可以像之前一样使用rpmbuild来生成rpm包了。
使用这种方式编译rpm包,无疑给开发者带来了很多方便,尤其是使用git做版本控制的开发者。而且也比debian打包简单,debian打包需要一个debian目录,里面一大堆文件,而rpm打包,一切尽在一个spec文件中,经典!
接下来说说python程序包的制作,这个比较特殊。
python应用程序的RPM包制作
正如前面所见的,rpmbuild内置了很多宏,使得在写rpm包时方便很多。所有这些宏都在/usr/lib/rpm/macros中定义。
查看python相关的宏:
$ cat /usr/lib/rpm/macros | grep python
%__python /usr/bin/python
%__python_provides /usr/lib/rpm/pythondeps.sh --provides
%__python_requires /usr/lib/rpm/pythondeps.sh --requires
# at the python prompt for example, after "import rpm".如上,在spec文件里可以使用%{__python}来调用系统python。
这里没有定义sitelib,我们一般在spec文件开头自定义:
%{!?python_sitelib: %define python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")}可以看出,%()里面是shell命令,通过python的get_python_lib函数得到python的site lib路径。
此外,还有安装要求:
BuildRequires: python-devel
%if 0%{?fedora} >= 8
BuildRequires: python-setuptools-devel
%else
BuildRequires: python-setuptools
%endif在安装部分,可以使用%{__python}宏来进行安装:
%install
rm -rf $RPM_BUILD_ROOT
%{__python} setup.py install --root $RPM_BUILD_ROOT–root $RPM_BUILD_ROOT的作用就是告诉setup.py安装到虚拟根上,类似前面的 RPM_INSTALL_ROOT=$RPM_BUILD_ROOT。
此外,这里还有一个INSTALLED_FILES标志可以使用,用来标记安装到系统中的文件,但来自fedoraproject的建议是,不提倡使用 INSTALLED_FILES,因为它只会标记文件,而不会标记目录,所以有可能遗漏。
打包文件列表部分写法如下:
%files
%defattr(-,root,root,-)
%attr(755,root,root) %{_bindir}/gistore
%{python_sitelib}/*
%doc /usr/share/doc/gistore/README
%doc /usr/share/doc/gistore/COPYING
%doc /usr/share/doc/gistore/CHANGELOG%files部分列出要打包的文件和目录,可以使用前面的标记安装文件,但最好的方法就是把文件或目录手动列出来。
%defattr(-,root,root,-)代表使用默认的文件和目录权限
%{_bindir}是系统bin目录,具体为/usr/bin/,这个目录下的文件一般是可执行的。
%doc 代表文档,可以这样写::
%doc README COPYING CHANGELOG
这样的话,rpmbuild会从源码根目录下复制上述文件到/usr/share/doc/%{name}-%{version}/目录下,而按照前面的那种三行的写法的话,是自定义doc文件夹的位置,可以看出,自定义的doc文件夹名称没有版本号。
写完了以后就可以打包了,打包过程和前面无异。
下次有时间的话,会讲如何进行多个子包的打包~
RPM打包step by step(1)
4月2日
最近学习rpm打包,参考ibm文档库里rpm打包的文章,结合自己的实践,总结如下,一来备忘,二来和大家交流。
和deb打包不同,rpm打包需要特定的目录及结构。查看rpm打包目录,以下为在CentOS5.5下的输出结果:
$ rpm --showrc|grep _topdir
-14: _builddir %{_topdir}/BUILD
-14: _rpmdir %{_topdir}/RPMS
-14: _sourcedir %{_topdir}/SOURCES
-14: _specdir %{_topdir}/SPECS
-14: _srcrpmdir %{_topdir}/SRPMS
-14: _topdir %{_usrsrc}/redhat
$ rpm --showrc|grep _usrsrc
-14: _topdir %{_usrsrc}/redhat
-14: _usrsrc %{_usr}/src
$ rpm --showrc|grep _usr
-14: _defaultdocdir %{_usr}/share/doc
-14: _topdir %{_usrsrc}/redhat
-14: _usr /usr
-14: _usrsrc %{_usr}/src经过层层寻找,最终发现打包目录在/usr/src/redhat目录下,看看目录结构:
$ tree /usr/src/redhat /usr/src/redhat |-- BUILD |-- RPMS | |-- athlon | |-- geode | |-- i386 | |-- i486 | |-- i586 | |-- i686 | `-- noarch |-- SOURCES |-- SPECS `-- SRPMS
其中BUILD存放编译生成的临时文件,RPMS存放根据各种构架生成的rpm包,SOURCES存放源码包,SPECS存放spec文件,SRPMS存放生成的SRPM包。
最简单例子
下面以hello world为例,构建一个最小化打包过程。
首先需要写一个SPEC文件hello.spce:
Summary: hello world rpm package Name: hello Version: 0.1 Release: 1 Source: hello-0.1.tar.gz License: GPL Packager: amoblin Group: Application URL: http://www.ossxp.com %description This is a software for making your life more beautiful! %prep %setup -q %build gcc -o hello hello.c %install install -m 755 hello /usr/local/bin/hello %files /usr/local/bin/hello
放到上述SPECS目录下。
然后一个源程序hello.c:
#include <stdio.h>
int main()
{
printf("Hello, World!\n");
return 0;
}存放在hello-0.1目录,然后打包放到SOURCES目录:
$ tar zcvf hello-0.1.tar.gz hello-0.1
hello-0.1/
hello-0.1/hello.c
$ sudo mv hello-0.1.tar.gz /usr/src/redhat/SOURCES在SPECS目录下使用rpmbuild进行打包:
$ cd /usr/src/redhat
$ sudo rpmbuild -ba hello.spec
...
Wrote: /usr/src/redhat/SRPMS/hello-0.1-1.src.rpm
Wrote: /usr/src/redhat/RPMS/i386/hello-0.1-1.i386.rpm这时会逐个运行hello.spec文件的内容,最终生成两个文件,一个包含源码的rpm包和一个二进制rpm包。
使用 -bs 选项只生成源码rpm包;使用 -bb 选项只生成rpm包。
查看rpm包信息和包内容:
$ rpm -qpi ../RPMS/i386/hello-0.1-1.i386.rpm
$ rpm -qpl ../RPMS/i386/hello-0.1-1.i386.rpm第一个命令的输出是spec文件的序言部分的内容,第二个命令的输出是%files部分的文件列表。
现在有个问题,打包目录在/usr/src/redhat下,需要root权限才能操作,太不方便了,能不能在用户自定义目录下打包呢?
自定义打包目录
我们可以通过修改topdir宏的值来自定义打包路径:
$ echo %_topdir $HOME/rpmbuild > ~/.rpmmacros这样再查看topdir的值会发现已变为用户主目录下rpm子目录了。这时修改文件就方便多了。
但在执行rpmbuild时仍会出问题:
$ rpmbuild -ba hello.spec
...
install: 无法删除 “/usr/local/bin/hello”: 权限不够
error: Bad exit status from /var/tmp/rpm-tmp.65773 (%install)
...这是因为rpmbuild在构建rpm包时会将程序安装一遍,然后再提取安装文件。由于需要复制二进制文件hello到系统目录/usr/local/bin/下,所以普通用户执行就报错了。
那么怎么办呢?这里需要使用虚拟根了。
修改spec文件,在Description段落前,URL字段之后增加一行:
BuildRoot: %{_builddir}/%{name}-root修改install段落,将绝对安装路径改为使用构建根的方式::
%install mkdir -p $RPM_BUILD_ROOT/usr/local/bin install -m 755 hello $RPM_BUILD_ROOT/usr/local/bin/hello
通过BuildRoot的值告诉rpmbuild,我们的构建根是builddir下的hello-root目录。其中以%{}括起来的是RPM宏,_builddir代表~/rpmbuild/BUILD目录;name代表spec文件开头的Name字段值。
以下划线开头的builddir是系统RPM宏,我们可以通过rpm –showrc看到,可以在.rpmmacros中自定义。
RPM_BUILD_ROOT和前面的宏不同,这里没有{}括起来,是为了在以后安装生成的rpm时不至于也去寻找传说中的构建根。
如果喜欢的话,可以修改Source字段如下::
Source: %{name}-%{version}.tar.gz好,继续回到构建根。现在执行rpmbuild,会在BUILD下创建hello-root目录作为虚拟根,hello安装在其中的usr/local/bin目录下。
使用Makefile
一般源程序都使用Makefile的,因此我们再进一步,添加一个Makefile文件,在spec里使用make来编译。
简单的Makefile文件如下:
SRC = hello.c
hello: $(SRC)
gcc $^ -o $@
clean:
rm -f hello
install:
-mkdir -p $(RPM_INSTALL_ROOT)/usr/local/bin/
install -m 755 hello $(RPM_INSTALL_ROOT)/usr/local/bin/hello由于使用了Makefile,我们最好升级一下版本号,将原先的hello-0.1目录复制为hello-0.2目录,放入Makefile文件。
修改spec文件,更新版本号,同时将build和install部分用make替换::
Version: 0.2 ... %build make %install RPM_INSTALL_ROOT=$RPM_BUILD_ROOT make install ...
这里将构建根参数传递给Makefile,从而将程序安装在指定的根目录下。
如果喜欢做事不留痕的话,可以在install段落后面增加clean段,清理生成的虚拟根:
%clean
rm -rf $RPM_BUILD_ROOT使用补丁文件
有很多源码包里都有补丁文件,在打包时要先打补丁,这也要在spec文件里告诉rpmbuild一声才行。
复制hello-0.2一份,随便修改一个hello.c,和原目录做比较,生成补丁文件:
$ cp -r hello-0.2 hello-0.2.my
$ vi hello-0.2.my/hello.c
$ diff -uNr hello-0.1 hello-0.2 > hello-0.1.patch然后修改spec文件,增加Patch字段,以及在prep段落增加打补丁动作::
...
Patch0: %{name}-%{version}.patch
...
%prep
%setup -q
%patch -p1
...Patch0告诉rpmbuild这是一个补丁,如果补丁不止一个的话,可以通过Patch1,Patch2增加。
再次执行rpmbuild,生成rpm包。
查看SRPM包内容:
$ rpm -qpl ../SRPMS/hello-0.2-1.src.rpm
hello-0.2.patch
hello-0.2.tar.gz
hello.spec补丁果然被打包进来了!
在安装过程中使用脚本
可以使用%pre,%post,%preun,%postun段落来定义安装前后,卸载前后的脚本动作::
%pre
echo This is pre for %{version}-%{release}: arg=$1
%post
echo This is post for %{version}-%{release}: arg=$1
%preun
echo This is preun for %{version}-%{release}: arg=$1
%postun
echo This is postun for %{version}-%{release}: arg=$1具体的脚本内容可自行替换。
打包rpm的过程就这么简单!
但上面这些方法一般都是针对打包者的,打包者不管以什么手段从任何地方得到了源代码包,然后保持一颗虔诚的心,恭恭敬敬地将之安放在rpmbuild/SOURCES目录下,然后天马行空,随意发挥或挥发,写下一篇洋洋洒洒的spec文件,对号入座到SPECS目录下,然后rpmbuild隆重出场,进行一系列生产加工,最终产生出来了传说中的rpm包和src.rpm包。
但,有时我们不总是打包者,更多时候我们是开发者,使用某种版本控制系统,比如Git,进行开发,最后的产品希望打包发布,还用上面的方式吗?不行,太麻烦了~
那怎么办呢?欲知结果,敬请期待,清明之后见分晓~
UNetbootin 让Linux安装更简单
9月9日
一般 Linux 的安装采用光盘的安装方式,上周在客户部署就遇到服务器没有光驱的情形,临时四处去借,好狼狈。
光盘安装还可能遇到一个问题就是:由于硬件太新而光盘内核太旧导致无法识别硬件,安装失败。
用网络安装是个好方法,但一个是部署麻烦,还有引入DHCP服务器可能会和用户网络中已有的DHCP冲突。
UNetbootin 提供了另一种解决方案:U盘启动。
U盘启动不是什么新鲜话题,但偶然发现的 UNetbootin 项目,让 U 盘启动 Linux 安装如此简单。
- 提供图形化界面,点点鼠标就搞定 Linux 启动 U 盘
- 虽然本身不提供多启动U盘制作,但可以很容易手工编辑启动菜单,实现多启动U盘
- Debian和Ubuntu的启动支持网络启动,还支持从U盘中的 ISO 镜像执行安装
如果U盘太小,不能放下太多的ISO镜像,那么就用网络安装。如果能架设一个 Debian/Ubuntu 的软件包缓存服务器,网络安装的效率可以达到或超过光盘安装。
nVidia 显卡在 Debian sarge 最新 linux 内核中的驱动
7月30日
我的笔记本安装的是 Debian sarge,上次升级内核到 linux 2.6.32-5, nVidia 的驱动就一直没有跑起来,今天下班后,仔细研究了一下。
先说一下 nouveau 和 nVidia 驱动的历史
Linux 和 Windows 相比,让用户觉得上手比较难,一个很重要的原因就是驱动不易安装。
- Windows 本身内置了大量的设备驱动
- 因为 Windows 的普及,硬件厂商首选是开发针对 Windows 的设备驱动
- 再有一个就是 Windows 升级比较缓慢,Windows XP 的历史都快10年了,硬件厂商的支持难度要小
就 nVidia 显卡来说,其实 Linux 的支持也是满不错的:
- Linux 内置了 nv 驱动:xserver-xorg-video-nv 。对 2D 支持尚可,3D 则是完全的不支持
- nVidia 官方曾经发布过开源的驱动 nvidia-glx 但不久就宣布不再支持。现在 nVidia 提供非开源的 Linux 驱动,在官网提供下载链接: http://www.nvidia.com/object/unix.html
- 因为 nVidia 官方的驱动和 Linux 操作系统的开放版权向背,各个 Linux 发行版都没有将 nVidia 官方的驱动集成到发行版中,造成用户安装 Linux 不能像 Windows 那样下载拆包即装的硬件驱动,只能使用功能较弱的内置驱动。
为了发挥显卡的最大功效,使用 3D 桌面或者运行 Google Earth 之类软件,我是这样安装 nVidia 驱动的:
- 首先在 Linux 中要安装 gcc,g++ 等软件开发环境,因为编译硬件驱动需要。
- 下载 nVidia 驱动。见官方驱动下载网页:http://www.nvidia.com/object/unix.html
- 启动 Linux 到文本控制台。如果进入了 X Window,需要杀掉 X,进入控制台界面。
- 运行从 nVidia 下载的软件包,按照界面一步一步操作,即可编译出内核模组和 Xorg 的设备驱动
- 编辑 /etc/X11/xorg.conf 设置: Driver “nvidia”
- 如果 Linux 升级?需要重新执行上面的步骤。
是不是太繁琐了?谁让你频繁升级呢? :-D
好消息是 Nouveau 来了,你看其中有字母 n 和 v,猜出来了么?这是 nVidia 在 Linux 下新的开源驱动名称。Nouveau 是通过针对 nVidia 显卡驱动反向工程,实现的 nVidia 开源显卡驱动,目标是提供完全的 3D 驱动支持。较 Linux 之前提供的 nv 驱动大大的前进了,甚至有一天会盖过官方的驱动。
阅读全部内容 »
Debian 文件偷换
7月9日
Debian “文件偷换”?在我们对开源软件定制的时候,用到了很多“偷换”的技术实现 Linux 的定制。当然群英汇大部分应用属于彻底的定制开发,采用软件包重新发布的形式提供服务。但是也有少部分的软件,例如 Apache2,PHP5,shorewall,只是对这些软件包自身的配置文件进行定制修改,这时如果采用软件包重新发布就显得非常笨拙和多此一举。采用配置文件“偷换”,起到事半功倍的效果。
为什么要文件“偷换”,而不是“光明正大”的覆盖呢?
- Debian 会检查文件包的文件冲突,不允许两个不同的软件包(A 和 B)安装相同的文件。
如果新安装的软件包(B)提供的文件已经由其它的软件包(A)安装过了,则拒绝安装新的软件包(B)。 - 如果新的软件包(B)在 POSTINST脚本(安装后自动执行的脚本)中,以拷贝文件的方式覆盖其它软件包(A)提供的文件,当然是可以的。但是,如果软件包A 有了新的版本,升级软件包A,会导致软件包B的定制文件被软件包A新的文件所覆盖。
Debian 本身提供的 dpkg-divert 提供了光明正大的文件“偷换”功能:
- 软件包 A 安装,配置文件保存在 /etc/a/file 中。
- 软件包 B 安装,执行 dpkg-divert 命令,声明将原来 /etc/a/file 移动到其它位置 /etc/other/place
- 软件包 B 自己的配置文件 /etc/b/file 链接到 /etc/a/file
- 软件包 A 升级的时候,会发现自己的配置文件 /etc/a/file 被指定到新位置 /etc/other/place,会将新的配置文件保存到 /etc/other/place 中。
Debian 文件偷换有两个常见的模式。
- 模式1:文件链接方式:
- 软件包 A 提供配置文件 /etc/file
- 软件包 B 提供配置文件 /etc/file.ossxp
- 软件包 B 的 postinst 脚本执行 dpkg-divert
- 将 /etc/file 重命名为 /etc/file.ossxp-orig
- 将 /etc/file.ossxp 链接为 /etc/file
- 模式2:文件移动方式
- 软件包 A 提供配置文件 /etc/fileA
- 软件包 B 提供配置文件 /etc/fileB。注意该配置文件不能是 /etc/fileA(第三模式)。
- 软件包 B 的 POSTINST 脚本执行 dpkg-divert,将 /etc/fileA 移动到 /usr/share/B/etc-fileA 中
在之前的一篇博客《群英汇部分应用的 /etc/init.d/ 下脚本名称改变》中曾经提到用 Debian Config Package 软件 和 CDBS 脚本,可以非常简单的实现上述两种文件偷换模式。而且根本无须编程,只是修改配置而已。
但是简单是有代价的。我们被限制在这两种“文件偷换”的模式中,而这两种模式都只在特定的场合可行,也就是说在特定情况下,都有副作用。当我们需要第三种模式的时候,就无法实现了,需要在彻底了解文件偷换机制后,脱离 CDBS ,手工编程实现。这两种模式有什么问题,以及怎么实现第三条道路呢?
阅读全部内容 »
LDAP 作为 FTP 认证源
6月29日
有很多用户都提出把 LDAP 和内部的 FTP 服务器整合的需求。好吧,就说一说三个主要的 FTP 服务器:vsftpd, Pure-FTPd 和 ProFTPD 和 LDAP 的整合。

最新评论