[arch-general] let's discuss /srv again
Hi, I want to discuss using /srv directory in packages (For reference: http://bugs.archlinux.org/task/16410) Of course I can easy sed and rebuild all my web packages, but I want to know reason why we disable /srv in packages? (Did I skip something?) **cut**
/srv and /home are different cases
/home often network or --bind mounted.
for example I use 4 chrooted environment to build packages with single /home (mounted with --bind key)
Most of distros I know (for example suse, alt, debian) use /srv (or /var/www) in packages. (I can not remember distro which disable it) **cut**
I do not want to split packages into /etc, /usr/share and /var folders with kludge symlinking. Would it be good if I replace /srv/http with /var/www/<package> or something like this?
2009/10/2 Sergej Pupykin <pupykin.s@gmail.com>:
Hi,
I want to discuss using /srv directory in packages
(For reference: http://bugs.archlinux.org/task/16410)
Of course I can easy sed and rebuild all my web packages, but I want to know reason why we disable /srv in packages?
IMO web apps should not even be packed as packages. It's easy to download sources from an official site and install in whatever user's webserver directory is. Yes, packaging a webapp is nice for automatic upgrading with pacman, but users can have multiple web servers with multiple vhosts in /srv, so often installing something there won't make it working anyway, and user will copy/move/symlink the app to whatever directory is right for user's webserver config scheme, which is against the idea that package files (except configs) should not be touched by user, but only by package manager.
Would it be good if I replace /srv/http with /var/www/<package> or something like this?
No, /var is not good either. I can think about something like /usr/share/src/<webapp>, but anyway that does not make much sense, comparing to just installing the sources manually. :-/ -- Roman Kyrylych (Роман Кирилич)
On Fri, 2 Oct 2009 10:47:24 +0300 Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2009/10/2 Sergej Pupykin <pupykin.s@gmail.com>:
Hi,
I want to discuss using /srv directory in packages
(For reference: http://bugs.archlinux.org/task/16410)
Of course I can easy sed and rebuild all my web packages, but I want to know reason why we disable /srv in packages?
IMO web apps should not even be packed as packages. It's easy to download sources from an official site and install in whatever user's webserver directory is. Yes, packaging a webapp is nice for automatic upgrading with pacman, but users can have multiple web servers with multiple vhosts in /srv, so often installing something there won't make it working anyway, and user will copy/move/symlink the app to whatever directory is right for user's webserver config scheme, which is against the idea that package files (except configs) should not be touched by user, but only by package manager.
Would it be good if I replace /srv/http with /var/www/<package> or something like this?
No, /var is not good either. I can think about something like /usr/share/src/<webapp>, but anyway that does not make much sense, comparing to just installing the sources manually. :-/
well it would at least give you the advantage of easier seeing if there are updates, updating, getting a list of installed webapps etc. I'm fine with packaged webapps where the webapps are installed in a dir which users are supposed to symlink to. so that it's still up to the user, but they get the advantages listed above. anything more then that gets icky: webapps come with config files, default sql data, upon upgrade you usually need to do several steps such as running a bunch of sql queries etc. stuff that should probably not be done automatically. Dieter
At Fri, 2 Oct 2009 10:47:24 +0300, Roman Kyrylych wrote:
IMO web apps should not even be packed as packages. It's easy to download sources from an official site and install in whatever user's webserver directory is. Yes, packaging a webapp is nice for automatic upgrading with pacman, but users can have multiple web servers with multiple vhosts in /srv, so often installing something there won't make it working anyway, and user will copy/move/symlink the app to whatever directory is right for user's webserver config scheme, which is against the idea that package files (except configs) should not be touched by user, but only by package manager.
If user wants big hosting he should install all files by himself. If user touches pacman-installed files he shout at his leg. But in referenced bug webapp is phpmyadmin (if I don't mistale it had more than 100 votes on aur). This app also usefull on localhost and has no need to copy it to vhosts directories. There are people who want it to be packaged and there are people who want to maintain it.
Roman Kyrylych a écrit :
2009/10/2 Sergej Pupykin <pupykin.s@gmail.com>:
Hi,
I want to discuss using /srv directory in packages
(For reference: http://bugs.archlinux.org/task/16410)
Of course I can easy sed and rebuild all my web packages, but I want to know reason why we disable /srv in packages?
IMO web apps should not even be packed as packages. It's easy to download sources from an official site and install in whatever user's webserver directory is.
I perfectly concur with this.
Yes, packaging a webapp is nice for automatic upgrading with pacman, but users can have multiple web servers with multiple vhosts in /srv, so often installing something there won't make it working anyway, and user will copy/move/symlink the app to whatever directory is right for user's webserver config scheme, which is against the idea that package files (except configs) should not be touched by user, but only by package manager.
Also, major php applications usually automatically notify the admin when there is an update. Drupal does it, and phpmyadmin probably too. So there is really *no need* to package them. Whatever I put under /srv/http comes from an upstream download. BTW, I just saw that nginx also does this: pacman -Qo /srv/http/nginx/50x.html /srv/http/nginx/50x.html is owned by nginx 0.7.62-1 In this case, this is not a webapp, but a web server. Still, this should go to /usr/share/nginx/ instead. Apache does it like this.
On Fri, 02 Oct 2009 10:58:19 +0200 Firmicus <Firmicus@gmx.net> wrote:
Roman Kyrylych a écrit :
Yes, packaging a webapp is nice for automatic upgrading with pacman, but users can have multiple web servers with multiple vhosts in /srv, so often installing something there won't make it working anyway, and user will copy/move/symlink the app to whatever directory is right for user's webserver config scheme, which is against the idea that package files (except configs) should not be touched by user, but only by package manager.
Also, major php applications usually automatically notify the admin when there is an update. Drupal does it, and phpmyadmin probably too. So there is really *no need* to package them. Whatever I put under /srv/http comes from an upstream download.
this is one of the reasons why many webapps suck. they add bloat such as package/software management features. imho it's not the task of the webapp to do this. and i hate configuring every webapp to do it. Dieter
On Friday 02 October 2009 04:13:13 am Dieter Plaetinck wrote:
Also, major php applications usually automatically notify the admin when there is an update. Drupal does it, and phpmyadmin probably too. So there is really *no need* to package them. Whatever I put under /srv/http comes from an upstream download.
this is one of the reasons why many webapps suck. they add bloat such as package/software management features. imho it's not the task of the webapp to do this. and i hate configuring every webapp to do it.
Dieter
+1 Even larger web apps with tight mysql dependencies, etc. are simple enough to install and usually come with good config scripts (Gallery2, eGroupWare, etc.). With web servers in many different locations for people that move to Arch, I think packaged web apps that try for a default "Arch" config could potentially cause more user headaches than they cure. SuSE and others have tried packaging web apps with limited success. The two exceptions to that are generally phpadministrator and phpmyadmin which I have seen successfully packaged by several distros. Just food for thought. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On Sun, Oct 4, 2009 at 10:36 AM, David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
On Friday 02 October 2009 04:13:13 am Dieter Plaetinck wrote:
Also, major php applications usually automatically notify the admin when there is an update. Drupal does it, and phpmyadmin probably too. So there is really *no need* to package them. Whatever I put under /srv/http comes from an upstream download.
this is one of the reasons why many webapps suck. they add bloat such as package/software management features. imho it's not the task of the webapp to do this. and i hate configuring every webapp to do it.
Dieter
+1
Even larger web apps with tight mysql dependencies, etc. are simple enough to install and usually come with good config scripts (Gallery2, eGroupWare, etc.). With web servers in many different locations for people that move to Arch, I think packaged web apps that try for a default "Arch" config could potentially cause more user headaches than they cure. SuSE and others have tried packaging web apps with limited success. The two exceptions to that are generally phpadministrator and phpmyadmin which I have seen successfully packaged by several distros.
Dieter was saying it would be better to manage webapps with the package manager. You are apparently saying the opposite. So why +1 ?
On Sunday 04 October 2009 04:42:19 am Xavier wrote:
On Sun, Oct 4, 2009 at 10:36 AM, David C. Rankin
<drankinatty@suddenlinkmail.com> wrote:
On Friday 02 October 2009 04:13:13 am Dieter Plaetinck wrote:
Also, major php applications usually automatically notify the admin when there is an update. Drupal does it, and phpmyadmin probably too. So there is really *no need* to package them. Whatever I put under /srv/http comes from an upstream download.
this is one of the reasons why many webapps suck. they add bloat such as package/software management features. imho it's not the task of the webapp to do this. and i hate configuring every webapp to do it.
Dieter
+1
Even larger web apps with tight mysql dependencies, etc. are simple enough to install and usually come with good config scripts (Gallery2, eGroupWare, etc.). With web servers in many different locations for people that move to Arch, I think packaged web apps that try for a default "Arch" config could potentially cause more user headaches than they cure. SuSE and others have tried packaging web apps with limited success. The two exceptions to that are generally phpadministrator and phpmyadmin which I have seen successfully packaged by several distros.
Dieter was saying it would be better to manage webapps with the package manager. You are apparently saying the opposite. So why +1 ?
Blame it on the flu, I was saying there is no need to package web apps as the only install configuration needed is to untar and uncompress them to your chosen directory and then run their configure script to setup and/or configure the database backend and then to configure the webserver if you installed outside of the document root. I think it would require way more code than necessary if the packager was also going to try and manage all of that to accommodate installs in standard and non standard locations. Don't get me wrong, I'm all for automated install scripts as long as the installer doesn't introduce more bugs along the way. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
Sergej Pupykin wrote:
Hi,
I want to discuss using /srv directory in packages
(For reference: http://bugs.archlinux.org/task/16410)
Of course I can easy sed and rebuild all my web packages, but I want to know reason why we disable /srv in packages?
(Did I skip something?)
**cut**
/srv and /home are different cases
/home often network or --bind mounted.
for example I use 4 chrooted environment to build packages with single /home (mounted with --bind key)
Most of distros I know (for example suse, alt, debian) use /srv (or /var/www) in packages. (I can not remember distro which disable it) **cut**
I do not want to split packages into /etc, /usr/share and /var folders with kludge symlinking.
Would it be good if I replace /srv/http with /var/www/<package> or something like this?
If packages start putting stuff in /srv as well, where are we supposed to put OUR data? You don't want to put your data where packages put data as well. Glenn
At Fri, 02 Oct 2009 10:10:56 +0200, RedShift wrote:
If packages start putting stuff in /srv as well, where are we supposed to put OUR data? You don't want to put your data where packages put data as well.
Why not? If you download for example dokuwiki you put your pages into ./data directory inside dokuwiki one by default. What difference is installed by pacman or by yourself? (Of course you can change data files placement) The same can be applied to mediawiki and some other packages.
Sergej Pupykin schrieb:
I do not want to split packages into /etc, /usr/share and /var folders with kludge symlinking.
Would it be good if I replace /srv/http with /var/www/<package> or something like this?
I would say, use /usr/share/www/ (or similar) for static/php files, and provide proper configuration files that set the correct Alias and Directory directives for popular servers like apache and lighttpd. Users can then use Include directives (in case of apache) to load those confighuration files and enable the web app.
I would say, use /usr/share/www/ (or similar) for static/php files, and provide proper configuration files that set the correct Alias and Directory directives for popular servers like apache and lighttpd. Users can then use Include directives (in case of apache) to load those confighuration files and enable the web app.
It is good idea, but it needs patching for most of webapps because of webapps configs should be in /etc and user data - in /var by default.
Sergej Pupykin schrieb:
I would say, use /usr/share/www/ (or similar) for static/php files, and provide proper configuration files that set the correct Alias and Directory directives for popular servers like apache and lighttpd. Users can then use Include directives (in case of apache) to load those confighuration files and enable the web app.
It is good idea, but it needs patching for most of webapps because of webapps configs should be in /etc and user data - in /var by default.
Patching them is overkill, it would be an example of the unnecessary patching we do not want in Arch. I would keep them self-contained, no matter which solution will be used in the end. I wouldn't even have such a big problem with having configuration in /usr/share/www/phpmyadmin/config.inc.php or so. In any way, filling /srv with data from pacman is a bad idea, /home and /srv should be user territory only.
Patching them is overkill, it would be an example of the unnecessary patching we do not want in Arch. I would keep them self-contained, no matter which solution will be used in the end. I wouldn't even have such a big problem with having configuration in /usr/share/www/phpmyadmin/config.inc.php or so.
In any way, filling /srv with data from pacman is a bad idea, /home and /srv should be user territory only. It is not problem for user, but as I understand it should not be modificable files in /usr/share/
Sergej Pupykin schrieb:
Patching them is overkill, it would be an example of the unnecessary patching we do not want in Arch. I would keep them self-contained, no matter which solution will be used in the end. I wouldn't even have such a big problem with having configuration in /usr/share/www/phpmyadmin/config.inc.php or so.
In any way, filling /srv with data from pacman is a bad idea, /home and /srv should be user territory only. It is not problem for user, but as I understand it should not be modificable files in /usr/share/
There are many "should"s here: - You should not unnecessarily patch applications. - You should not fill /srv or /home with pacman data - You should not put user-modifiable files in /usr/share The last "should" is IMO the weakest of all. You can easily avoid violating the first two though. I would say this is the best solution, but it would be great to have some more opinions from other devs and TUs here, maybe even some from our overlord. As for not packaging phpmyadmin and similar: I am with Dieter here, a webapp shouldn't include a package manager, we should rather use the existing package manager to track the webapp if we want to - so IMO it is legitimate to have these things in pacman. I'll also provide a short example of a /etc/httpd/conf/extra/httpd-phpmyadmin.conf file: # phpMyAdmin Alias /phpMyAdmin /usr/share/www/phpmyadmin <Directory "/usr/share/www/phpmyadmin"> AllowOverride None Options None Order allow,deny Allow from 127.0.0.1 </Directory> If you also include a similar file for lighttpd, it should be fine.
I put new phpmyadmin into community-testing To use it you should: - add FollowSymlinks options - append directories to php.ini open_basedir = /usr/share/webapps/:/etc/webapps - change web-alias to /usr/share/webapps/phpMyAdmin What do you think about this solution? (I hope all webapps can be adjusted with symlinking)
Sergej Pupykin schrieb:
I put new phpmyadmin into community-testing
To use it you should: - add FollowSymlinks options - append directories to php.ini open_basedir = /usr/share/webapps/:/etc/webapps - change web-alias to /usr/share/webapps/phpMyAdmin
What do you think about this solution?
(I hope all webapps can be adjusted with symlinking)
Ugh, I forgot the open_basedir problem. I'll look at what you did and will comment on it later. Generally I don't like having FollowSymlinks enabled.
Ugh, I forgot the open_basedir problem. I'll look at what you did and will comment on it later. Generally I don't like having FollowSymlinks enabled.
open_basedir can be adjusted one time if we use common dirs for all webapps (/etc/webapps and /usr/share/webapps) I think symlink is the single way to keep proper directory structure. I check debian as reference - it does so.
2009/10/2 Sergej Pupykin <pupykin.s@gmail.com>:
I put new phpmyadmin into community-testing
To use it you should: - add FollowSymlinks options - append directories to php.ini open_basedir = /usr/share/webapps/:/etc/webapps - change web-alias to /usr/share/webapps/phpMyAdmin
What do you think about this solution?
Safe Mode (which includes open_basedir) is deprecated in PHP 5.3, and will be removed in 6.0.0. -- Roman Kyrylych (Роман Кирилич)
Am Freitag 02 Oktober 2009 16:51:55 schrieb Roman Kyrylych:
Safe Mode (which includes open_basedir) is deprecated in PHP 5.3, and will be removed in 6.0.0.
No, safe_mode and open_basedir are different features and only safe_mode is deprecated. The usage of open_basedir is recommend. -- Pierre Schmitz, http://users.archlinux.de/~pierre
On Fri 02 Oct 2009 12:23 +0200, Thomas Bächler wrote:
Sergej Pupykin schrieb:
Patching them is overkill, it would be an example of the unnecessary patching we do not want in Arch. I would keep them self-contained, no matter which solution will be used in the end. I wouldn't even have such a big problem with having configuration in /usr/share/www/phpmyadmin/config.inc.php or so.
In any way, filling /srv with data from pacman is a bad idea, /home and /srv should be user territory only. It is not problem for user, but as I understand it should not be modificable files in /usr/share/
There are many "should"s here:
- You should not unnecessarily patch applications. - You should not fill /srv or /home with pacman data - You should not put user-modifiable files in /usr/share
The last "should" is IMO the weakest of all. You can easily avoid violating the first two though. I would say this is the best solution, but it would be great to have some more opinions from other devs and TUs here, maybe even some from our overlord.
If you're asking for opinions, I think that the web apps should go into /usr/share/<pkgname> then the user can then copy the data over to suit their web server set up.
On Fri, Oct 2, 2009 at 13:23, Thomas Bächler <thomas@archlinux.org> wrote:
Sergej Pupykin schrieb:
>> Patching them is overkill, it would be an example of the unnecessary patching we do not want in >> Arch. I would keep them self-contained, no matter which solution will be used in the end. I >> wouldn't even have such a big problem with having configuration in >> /usr/share/www/phpmyadmin/config.inc.php or so.
In any way, filling /srv with data from pacman is a bad idea, /home and /srv should be user territory only.
It is not problem for user, but as I understand it should not be modificable files in /usr/share/
There are many "should"s here:
- You should not unnecessarily patch applications. - You should not fill /srv or /home with pacman data - You should not put user-modifiable files in /usr/share
The last "should" is IMO the weakest of all. You can easily avoid violating the first two though. I would say this is the best solution, but it would be great to have some more opinions from other devs and TUs here, maybe even some from our overlord.
Modifiable files are not allowed in /usr/share according to FHS. But we have /opt which is intended for self-containing apps which is exactly what webapps are. -- Roman Kyrylych (Роман Кирилич)
Sergej Pupykin a écrit :
I would say, use /usr/share/www/ (or similar) for static/php files, and provide proper configuration files that set the correct Alias and Directory directives for popular servers like apache and lighttpd. Users can then use Include directives (in case of apache) to load those confighuration files and enable the web app.
It is good idea, but it needs patching for most of webapps because of webapps configs should be in /etc and user data - in /var by default.
This is why I think it is a waste of (your) time to do this ;)
participants (10)
-
David C. Rankin
-
Dieter Plaetinck
-
Firmicus
-
Loui Chang
-
Pierre Schmitz
-
RedShift
-
Roman Kyrylych
-
Sergej Pupykin
-
Thomas Bächler
-
Xavier