let's discuss /srv again

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

let's discuss /srv again

Sergej Pupykin-3
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?
Reply | Threaded
Open this post in threaded view
|

Re: let's discuss /srv again

Roman Kyrylych
2009/10/2 Sergej Pupykin <[hidden email]>:
> 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 (Роман Кирилич)
Reply | Threaded
Open this post in threaded view
|

Re: let's discuss /srv again

RedShift
In reply to this post by Sergej Pupykin-3
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
Reply | Threaded
Open this post in threaded view
|

Re: let's discuss /srv again

Dieter Plaetinck
In reply to this post by Roman Kyrylych
On Fri, 2 Oct 2009 10:47:24 +0300
Roman Kyrylych <[hidden email]> wrote:

> 2009/10/2 Sergej Pupykin <[hidden email]>:
> > 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
Reply | Threaded
Open this post in threaded view
|

Re: let's discuss /srv again

Sergej Pupykin-3
In reply to this post by Roman Kyrylych
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.
Reply | Threaded
Open this post in threaded view
|

Re: let's discuss /srv again

Sergej Pupykin-3
In reply to this post by RedShift

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.
Reply | Threaded
Open this post in threaded view
|

Re: let's discuss /srv again

Firmicus
In reply to this post by Roman Kyrylych
Roman Kyrylych a écrit :

> 2009/10/2 Sergej Pupykin <[hidden email]>:
>  
>> 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.


Reply | Threaded
Open this post in threaded view
|

Re: let's discuss /srv again

Dieter Plaetinck
On Fri, 02 Oct 2009 10:58:19 +0200
Firmicus <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: let's discuss /srv again

Thomas Bächler-3
In reply to this post by Sergej Pupykin-3
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.


signature.asc (269 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: let's discuss /srv again

Sergej Pupykin-3
 >> 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.
Reply | Threaded
Open this post in threaded view
|

Re: let's discuss /srv again

Thomas Bächler-3
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.


signature.asc (269 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: let's discuss /srv again

Firmicus
In reply to this post by Sergej Pupykin-3
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 ;)
Reply | Threaded
Open this post in threaded view
|

Re: let's discuss /srv again

Sergej Pupykin-3
In reply to this post by Thomas Bächler-3
 >> 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/
Reply | Threaded
Open this post in threaded view
|

Re: let's discuss /srv again

Thomas Bächler-3
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.



signature.asc (269 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: let's discuss /srv again

Sergej Pupykin-3
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)
Reply | Threaded
Open this post in threaded view
|

Re: let's discuss /srv again

Loui Chang
In reply to this post by Thomas Bächler-3
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.

Reply | Threaded
Open this post in threaded view
|

Re: let's discuss /srv again

Thomas Bächler-3
In reply to this post by Sergej Pupykin-3
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.


signature.asc (269 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: let's discuss /srv again

Sergej Pupykin-3
 >> 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.
Reply | Threaded
Open this post in threaded view
|

Re: let's discuss /srv again

Roman Kyrylych
In reply to this post by Sergej Pupykin-3
2009/10/2 Sergej Pupykin <[hidden email]>:
> 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 (Роман Кирилич)
Reply | Threaded
Open this post in threaded view
|

Re: let's discuss /srv again

Roman Kyrylych
In reply to this post by Thomas Bächler-3
On Fri, Oct 2, 2009 at 13:23, Thomas Bächler <[hidden email]> 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 (Роман Кирилич)
12