在tinycolinux上编译seafile

本文关键字:tinycorelinux上从0源码编译seafile,uswgi方式配置运行seafile

计算机科学和编程艺术起源于西方,在基础建设级很难发现中国人的建树,比如在C系相关的系统领域国内是没有什么作品广泛使用并让别人记住的,,但一个有趣的现象是,py域和应用域中国人异常活跃,且有不少佳品的,比如coco2dx,还比如我们要谈到的seafile,《在tinycolinux上编译odoo》一文中我们把曾odoo称为mineportalv2 - 它是groupware,vs odoo,seafile更接近personalware,其实更适宜用来打造mineportalv2,mineportalv1 oc只是一个复杂的图床加面向同步的webdav支持,而seafile有独立的fileserver,支持免文档数据库的切片文件系统,独立的standlone fileserver targetting storage domain logic implented as enginx appstack componet也有利于我们研究将其与enginx中的其它部件集成及深入《发布enginx》一文中的课题研究,且程序实现上鲜明的c+py混合编程特征和综合web+websocket的自然混合程序设计,更适合被用来作为教育目的,当然它不像OC一样仅需要虚拟空间就可以运行,只是这在云主机低价盛行的今天也不是什么大事了。因此接下来我们在tinycolinux上一步一步编译它:

编译seafile的五大件:

我们首先编译出GCC481和CMAKE,python+pip,nginx等,按《在tinycolinux中编译cling混合c和py在线学习系统》中说的一步一步完成,且准备gcc的autotools支持和git支持:

autogen.tcz,automake.tcz,autoconf.tcz,libtool.tcz,intltool.tcz,perl5.tcz,git.tcz,openssl-1.0.0.tcz

然后编译出五大件,我下载到的版本是:

jansson-2.10.tar.gz(一个json解析库,C项目,cmake或autotools构建)

libevhtp-1.1.6.tar.gz(一个强化libevent的http库,c项目,cmake构建)

seafile-6.1.1.tar.gz(seafile的,c+py混合项目as pylib,autotools构建。)

seahub-6.2.5-server.tar.gz(纯py,django app,seafile的前端部分)

按依赖和先后顺后编译,使用到autotools一般都是先sudo autogen.sh,然后./configure,如果sudo autogen.sh之后产生不了makefile.in基本是libtool的问题,确认安好libtool.tcz解决它,一一./configure --prefix=/usr/local/seafile之后,基本都能完成,使用到cmake一般要shadowbuild,即sudo mkdir b到src下,然后cd b,sudo cmake .. && sudo cmake build ..,其中evhtp要sudo cmake -DEVHTP_DISABLE_SSL=ON ..,libevhtp-1.1.6.tar.gz中cmakelists.txt中取消三个test的编译需求。编译configure或link过程中的时候会调到下述tcz:

acl-dev.tcz,acl.tcz,bzip2-dev.tcz,bzip2-lib.tcz,bzip2.tcz,curl-dev.tcz,curl.tcz,expat2-dev.tcz,expat2.tcz,fuse.tcz,glib2-dev.tcz,glib2.tcz,guile-dev.tcz,guile.tcz

libarchive-dev.tcz,libarchive.tcz,libattr.tcz,libevent-dev.tcz,libevent.tcz,libffi-dev.tcz,libffi.tcz,libltdl.tcz,liblzma-dev.tcz,liblzma.tcz,libssh2-dev.tcz,libssh2.tcz,popt-dev.tcz,popt.tcz,vala.tcz

基本上,,都可以在4.x的tinycorelinux tcz repos中找到。自己整理一下对应关系,假设在第一步我们上述五个除seahub外都是安装到/usr/local/seafile的,所有成功结果会是这样:在/usr/local/bin下产生各种bin,在/usr/local/seafile/lib/产生ccnet,seafile,serpc的so,la,甚至在/usr/local/bin中也产生了seafile-admin:没有py后缀shebang为py,作为脚本使用)。这个脚本很重要,下面细说.

安装配置seafile并用nginx+uwsgi方式启动:

首先创建一个仓库(相当于odoo刚装完或重新配置时,要进入web/database/manager删减数据套件一样),seafile-admin就是用来产生这个套件的总工具,并负责调用seahub根下的manage.py来启动,下面我们用官方方法-即seafile-admin来产生套件并启动它:

在任意目录新建一个data文件夹,然后产生data/seafile-server/seahub的空文件结构,把五大件中的seahub改名替换/data/seafile-server/seahub中的seahub,四大件要么作为后端,要么sudo make install到并作为python lib,seahub中也有一部分要作为python lib,因此,export PYTHONPATH=/xxx/seafile-server/seahub/thirdpart一下,除去所有这些不可见部分,此后的seahub就相当于整个seafile website了。------- 现在,可以执行产生数据仓库(我们把它称为数据套件吧)的总脚本了,就是那个seafile-admin setup,回答所有问题后发现正确配置完成,pip install gnicore后即可访问,我们看到帮助文档中配合nginx是转发gnicore的数据,现在,我们将django的这种方式,换成nginx+uwsgi,去掉gunicore的必要。这实际属于django nginx uwsgi搭配问题。

首先,我们有如下发现:/usr/local/seafile/data/seafile-server/seahub/seahub下有一个wsgi.py和settings.py,这符合我们在《发布odoo》中用nginx+uwsgi将其启动的改造方式,也就是说,它可能天然支持纯uwsgi且seafile也保留了这种方式,那么究竟是不是呢?

进一步通过观看seafile-admin我们进一步明确了这种设想:它负责配置逻辑的产生(django app settings),且它调用的manage.py仅是一个wsgi.py的wrapper(为了seafile-admin中统一gunicore,fastcgi,etc..),所以,在seafile-admin->manage.py->wsgi.py的调用路径中,这样seafile-admin既是产生套件的工具,也用于统一启动,而原本这一切:用于seafile-admin中读取配置的部分settings.py+负责启动的部分wsgi,在无外头wrapper即seafile-admin情况下,它们是分离直接放进seahub根下的settings.py和wsgi.py中的:

现在既然有数据套件和套件配置了,所以尝试直接配置uwsgi和nginx启动这个套件下的seafile就够了,其它可按《odoo》一文中的来,成功!:

nginx配置逻辑:

include uwsgi_params;

uwsgi_param UWSGI_CHDIR /usr/local/seafile/data/seafile-server/seahub/seahub;

uwsgi_param UWSGI_MODULE uwsgi-server; (不需要.py)

uwsgi_param UWSGI_CALLABLE application;

uwsgi_pass 127.0.0.1:8000;

启动的逻辑:

/usr/local/seafile/sbin/nginx

/usr/local/seafile/bin/uwsgi --socket=:8000 --master --uid=tc --gid=root --daemonize=/usr/local/seafile/bin/uwsgi.log

好吧,自己DIY着去HIGH吧。恩恩

-----------------

关于我,关注“shaolonglee公号”

  • 发表于:
  • 原文链接:http://kuaibao.qq.com/s/20180125G00AL100?refer=cp_1026

同媒体快讯

相关快讯

扫码关注云+社区