提供Magic Linux---基本服务器套装（PHP环境）

haulm

其实以前我打的包还包括了图形界面管理的bind、dhcp等，现在一时也想不起来这些开源软件的相关官方网址，以前上传的一些包也随着我自己的空间(以前帮朋友管理了几年的网站)消失而消失。

感觉自己也不过学了些rpm包制做方法，目前FC的打包似乎都成了默认的标准了，各种编译只能在其基础上再根据实际需要和当前系统的一些差别重新打包。我不觉得打包是种快乐，因为打包你安装的东西比服务器用户还要多。

mail服务是我一直头痛的东西，网络上基本没有可用的安装文档，到处是传抄的旧资料，目前只有xmail我比较熟悉，它没有一大堆的安全整合问题。PHP的imap之mail()也不安全，我已经觉得根本不必要为PHP打包imap功能。PHP对网络的支持是广泛的，你根本可以通过PHP和mail客户账号连接正常的MAIL服务器进行操作。所以如果你不想开发一个象163等的电子邮局根本没必要为PHP架设一个邮件服务器，所以以后的打包或许不会再有imap支持。有点我觉得很奇怪，网络上有N个传抄的所谓安装指南，却没有一个src.rpm包出现。

KDE的方案并不可行，最好的解决办法是专门开发一个图形界面的安装程序来实现整个服务器的配置，或者开发MGC服务器版本。

目前我的服务器新的打包试验都在EVL上，如果需要等它成熟时应该会在MGC上再现吧。

npcomet

    
今天我还想吧 apache的所有模块全部编译 然后一块装上 不检查依赖性

haulm

FC的打包是很奇怪的，它只考虑模块的分割，而不考虑整体运作的效能。所以FC不可能成为一个好的桌面，也不会是个好的服务器。但也正因为FC如此打包才使得它的源码包成为一个万能的源码包编译标准。

我很难理解FC打包一个软件对一个安装包进行不同的多次的编译，有时甚至是对不同版本的源码包进行编译，然后产生一堆二进制文件进行rpm打包，这些包是用不同参数，不同编译时间甚至同一软件不同版本产生的模块集合体，如果你也能进行正常工作，但并不象你想象中的那样安全和稳定。

之所以会有以上的说法是因为我曾经用FC编译PHP的方法打包并安装了所有包，在数倍于正常源码编译时长安装了一大堆连自己都分不清东西南北的RPM包后正常运用一些时间，但在一次操作后发现了一堆莫名其妙的权限问题（phpmyadmin不能对mysql进行稍有权限的工作），最后用phpinfo()查看到的编译参数是一堆前后完全相反矛盾交织的数据（对同一模块编译允许和不允许都存在的参数）时才有所感悟。

对服务器和软件的分包分割我已经不很信赖FC了，更多的是要考虑是否有必要分割，去掉我们系统中认为没有必要加入的内容，从软件或服务器软件官方的安装文档中得到正确编译的方法才能去决定自己的打包是否合理。

npcomet

其实我最感觉奇怪的是rpm（src.rpm）的两次压缩
让人受不了

haulm

我考虑的是：国内是否存在不少真正理解Linux并打包的高级玩家，是否国内只有一些简单的Linux尝鲜玩家和一些普通应用玩家，或者只是存在一些少有的高手但却是源码编译狂人。

FC的打包并非就是科学无误的，而且它的编译从头到脚都为了整个FC系统的需求，FC编译包中的补丁有时连补丁都算不上，我发现有的N个补丁只不过是修改makefile进行编译参数的设置罢了，编译参数设置也搞成补丁格式也是我以前根本没有想到的。

我没有理由不相信，任何的官方软件都有了很好的发展，而且不需要任何的补丁，FC的补丁完全是为了自身的需要对软件进行了修改，所以直接使用FC的源码包也是不科学的，甚至我根据一些朋友源码打包学习的资料进行编译打包的RPM包都比在其它系统上按照FC的src.rpm包编译来得更为科学。

我在使用国产Linux并尝试打包时发现了不少RH的影子，特别是桌面系统在安全协议软件时保留了对rh服务的“补丁”，这些“补丁”虽然不会对桌面影响，但打包却是失败的。一旦你想在桌面基础上建立服务系统，那么要么把你现有的桌面系统变回FC（简单地说根本就是FC的精简版），要么就面对痛苦地去研究各种服务不带FC系统特色的源码安装编译。而这方面资料太旧了、太少了、太多抄袭、太肤浅了。

npcomet

rpm在打包的时候就必须考虑可升级性
如果仅仅是为打包而打包的话，这个包几乎没有什么可升级性，最好的安装方法是先删除，然后重新安装。

打包的时候如果不考虑升级脚本的编写rpm根本也就没有什么魅力。

haulm

[quote:53c27cdd49="npcomet"]rpm在打包的时候就必须考虑可升级性
如果仅仅是为打包而打包的话，这个包几乎没有什么可升级性，最好的安装方法是先删除，然后重新安装。

打包的时候如果不考虑升级脚本的编写rpm根本也就没有什么魅力。[/quote]

呵呵，由从这点我发现了rpm包管理机制中存在的毛病，一方面是把软件拆散成N多个分包进行安装，这些包相互依赖或者不依赖，如果我考虑到升级，我很可能会因会各种原因只升级了这个软件其中的一部份，那么我的系统当中的这个软件有一部份是低版本的模块而另一部份是高版本模块。

事实上毛病还不仅是这么一点，在FC的PHP打包中我尝到了这种打包方式的困惑，将PHP按照不同的参数进行数次的编译，然后把它们生成的模块分类打包，你能告诉我，这样的RPM分包你安装也放心，并当成标准，奉为稳定？我看连PHP开发小组都不能判定这种打包方式后安装的服务存在哪些不稳定因素。。。

从学习PHP到了解一些Linux服务器打包方法后，我对FC的打包越来越不理解，他们甚至把不同版本的包进行分别编译后打包在一起，这种做法是否对开发者和使用者都极为不负责任？

我在EVL的一些言论，CJACKER也不能理解，如果国内没有力量组织自己特色的服务，那么还谈何桌面。我所理解的桌面不过是服务器的精简版本，而不是独立的桌面，或许有朋友有不同意见。

言多无益，只有等我在充分理解、编译和应用Linux服务软件后才能对Linux服务有个整体的认识，到时我才有清晰的头脑去评判一个Linux系统的安全、性能和特色。

npcomet

关于服务器其实windows平台上面的apache+php是最方便的极其组合容易，根本无须乱七八糟的依赖性，抛弃性能不说这样一次成型的方法还是不错的。

其实没有几个人建议服务器上面用rpm包的，一般都是自己编译的，自己可以控制更多的东西，不过入门就变的不容易了。

haulm

我几乎在EVL和MGC支持论坛上讨论这个话题，虽然我个人的能力太小了，而且我一直还是Linux服务软件的门外汉，但我已经决定以自己的力量先去闯国产Linux的服务器增值套件这个项目。

我所从事的也就是把开源的服务器软件和服务器管理软件打成RPM包，做成默认就能简单应用的服务器基础，并且默认这些服务不对外提供任何连接的整个体系。这个过程我不会抄袭FC的分包方法，类似上面讨论的，做为服务器应用根本不能考虑把所有的服务器模块做成动态并且编译参数混乱地生成模组然后打包安装，那样的不叫服务器，只能算是散装零件的组合，服务器是完整的，打碎了再装在一起，连服务器开发者都无法了解它存在的危机。

我考虑在我了解并把一些常用的服务器软件打成适用于桌面基础增值服务的包后下一步就是做一个合适又透明的安装格式，将这个东西发布出去。

现在大话说在了前头，何去何从，大家不必笑话。

npcomet

其实haulm无须固守rpm
你可以试一试bin打包