Re: [arch-projects] [PATCH 4/4] fhs: disallow installing in /srv
On Sun, Feb 26, 2012 at 4:20 PM, Tom Gundersen t...@jklm.no wrote: On Sun, Feb 26, 2012 at 3:46 PM, Seblu se...@seblu.net wrote: On Sun, Feb 26, 2012 at 2:56 PM, Tom Gundersen t...@jklm.no wrote: /srv is admin territory, similar to /home. No package should put stuff there. Are you sure of this? Currently many http packages use /srv/http to put static files. e.g backuppc, flyspray, roundcube... http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM The consensus seems to be that we don't let packages put stuff in /srv, so I thought it would make sense to let namcap reflect this. Sure ! I just wondering what is the arch way of doing web package :) -- Sébastien Luttringer www.seblu.net
Re: [arch-projects] [PATCH 4/4] fhs: disallow installing in /srv
On Tue, Feb 28, 2012 at 3:34 PM, Seblu se...@seblu.net wrote: On Sun, Feb 26, 2012 at 4:20 PM, Tom Gundersen t...@jklm.no wrote: On Sun, Feb 26, 2012 at 3:46 PM, Seblu se...@seblu.net wrote: On Sun, Feb 26, 2012 at 2:56 PM, Tom Gundersen t...@jklm.no wrote: /srv is admin territory, similar to /home. No package should put stuff there. Are you sure of this? Currently many http packages use /srv/http to put static files. e.g backuppc, flyspray, roundcube... http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM The consensus seems to be that we don't let packages put stuff in /srv, so I thought it would make sense to let namcap reflect this. Sure ! I just wondering what is the arch way of doing web package :) -- Sébastien Luttringer www.seblu.net Take a look out phpmyadmin -- Jelle van der Waa
Re: [arch-projects] [PATCH 4/4] fhs: disallow installing in /srv
On Tue, Feb 28, 2012 at 3:51 PM, Jelle van der Waa je...@vdwaa.nl wrote: On Tue, Feb 28, 2012 at 3:34 PM, Seblu se...@seblu.net wrote: On Sun, Feb 26, 2012 at 4:20 PM, Tom Gundersen t...@jklm.no wrote: On Sun, Feb 26, 2012 at 3:46 PM, Seblu se...@seblu.net wrote: On Sun, Feb 26, 2012 at 2:56 PM, Tom Gundersen t...@jklm.no wrote: /srv is admin territory, similar to /home. No package should put stuff there. Are you sure of this? Currently many http packages use /srv/http to put static files. e.g backuppc, flyspray, roundcube... http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM The consensus seems to be that we don't let packages put stuff in /srv, so I thought it would make sense to let namcap reflect this. Sure ! I just wondering what is the arch way of doing web package :) what's about adding /etc/webapps and /usr/share/webapps in php.ini ? We already add /srv/http. -- Sébastien Luttringer www.seblu.net
Re: [arch-projects] [PATCH 4/4] fhs: disallow installing in /srv
On Tue, Feb 28, 2012 at 5:59 PM, Seblu se...@seblu.net wrote: On Tue, Feb 28, 2012 at 3:51 PM, Jelle van der Waa je...@vdwaa.nl wrote: On Tue, Feb 28, 2012 at 3:34 PM, Seblu se...@seblu.net wrote: On Sun, Feb 26, 2012 at 4:20 PM, Tom Gundersen t...@jklm.no wrote: On Sun, Feb 26, 2012 at 3:46 PM, Seblu se...@seblu.net wrote: On Sun, Feb 26, 2012 at 2:56 PM, Tom Gundersen t...@jklm.no wrote: /srv is admin territory, similar to /home. No package should put stuff there. Are you sure of this? Currently many http packages use /srv/http to put static files. e.g backuppc, flyspray, roundcube... http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM The consensus seems to be that we don't let packages put stuff in /srv, so I thought it would make sense to let namcap reflect this. Sure ! I just wondering what is the arch way of doing web package :) what's about adding /etc/webapps and /usr/share/webapps in php.ini ? We already add /srv/http. Looking inside repositories for examples, phpmyadmin look like an exception. We lack of clean rules and a cleanning of our web packages. What's about a /var/lib/webapps to have writable content outside /usr ? Wiki suggest to symlink /var/lib to /usr/share/webapps? -- Sébastien Luttringer www.seblu.net
Re: [arch-projects] [PATCH 4/4] fhs: disallow installing in /srv
On Tue, Feb 28, 2012 at 11:08 AM, Seblu se...@seblu.net wrote: On Tue, Feb 28, 2012 at 5:59 PM, Seblu se...@seblu.net wrote: what's about adding /etc/webapps and /usr/share/webapps in php.ini ? We already add /srv/http. Looking inside repositories for examples, phpmyadmin look like an exception. We lack of clean rules and a cleanning of our web packages. What's about a /var/lib/webapps to have writable content outside /usr ? Wiki suggest to symlink /var/lib to /usr/share/webapps? imo, which is the only relevant opinion [sarcasm], these things should be in /usr/share/{pkgname} like anything else, with upload directories/etc configured to /var/lib/{pkgname}. phpmyadmin (on debian?) IIRC works like this -- nothing should be writing to /etc, and preferably nothing should be writing to /usr/share either (locale-gen is the only tool i know off-hand that does this regularly, and is incorrect imo). on other distros these webapps are enabled by dropping configuration files in /etc/httpd/* ... it would be nice to have a generic way of specifying installation details (vs. just assuming apache2, which bytes compared to uwsgi/mongrel2/nginx/{insert-here}) -- C Anthony
Re: [arch-projects] [PATCH 4/4] fhs: disallow installing in /srv
If all packages should install into /usr/share instead of /srv, how about a TODO? I can create it if there is consensus that it's a good idea. - Alexander
[arch-projects] [PATCH 4/4] fhs: disallow installing in /srv
/srv is admin territory, similar to /home. No package should put stuff there. The filesystem package does install /srv/ftp and /srv/http, but that's my problem to worry about (and namcap can't deal with the filesystem package anyway). Signed-off-by: Tom Gundersen t...@jklm.no --- Namcap/rules/fhs.py |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Namcap/rules/fhs.py b/Namcap/rules/fhs.py index 09180f6..9f555fa 100644 --- a/Namcap/rules/fhs.py +++ b/Namcap/rules/fhs.py @@ -26,7 +26,7 @@ class FHSRule(TarballRule): description = Checks for standard directories. def analyze(self, pkginfo, tar): valid_paths = [ - 'etc/', 'opt/', 'srv/', + 'etc/', 'opt/', 'lib/depmod.d', 'lib/firmware', 'lib/initcpio', 'lib/modprobe.d', 'lib/modules', 'lib/security', 'lib/udev', 'usr/bin/', 'usr/include/', 'usr/lib/', 'usr/lib32/', -- 1.7.9.2
Re: [arch-projects] [PATCH 4/4] fhs: disallow installing in /srv
On Sun, Feb 26, 2012 at 2:56 PM, Tom Gundersen t...@jklm.no wrote: /srv is admin territory, similar to /home. No package should put stuff there. Are you sure of this? Currently many http packages use /srv/http to put static files. e.g backuppc, flyspray, roundcube... http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM -- Sébastien Luttringer www.seblu.net
Re: [arch-projects] [PATCH 4/4] fhs: disallow installing in /srv
Where should WordPress put the files if not in /srv/http? In /usr/lib/wordpress, with a script that copies the relevant files into /srv/http? -- Cordially, Alexander Rødseth Arch Linux Trusted User (xyproto on IRC, trontonic on AUR)
Re: [arch-projects] [PATCH 4/4] fhs: disallow installing in /srv
On 02/26/2012 05:11 PM, Alexander Rødseth wrote: Where should WordPress put the files if not in /srv/http? In /usr/lib/wordpress, with a script that copies the relevant files into /srv/http? /usr/share/webapps if i recall, phpmyadmin is packaged correctly. -- Ionuț signature.asc Description: OpenPGP digital signature
Re: [arch-projects] [PATCH 4/4] fhs: disallow installing in /srv
On Sun, Feb 26, 2012 at 3:46 PM, Seblu se...@seblu.net wrote: On Sun, Feb 26, 2012 at 2:56 PM, Tom Gundersen t...@jklm.no wrote: /srv is admin territory, similar to /home. No package should put stuff there. Are you sure of this? Currently many http packages use /srv/http to put static files. e.g backuppc, flyspray, roundcube... http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM The consensus seems to be that we don't let packages put stuff in /srv, so I thought it would make sense to let namcap reflect this. Though one should keep in mind that namcap can be ignored if you must and you know what you are doing. This was discussed before, see [0] for an example. Cheers, Tom [0] http://mailman.archlinux.org/pipermail/arch-general/2009-October/007800.html