[ php-blog-Bugs-2992079 ] make s9y friendlier for downstream

Bugs item #2992079, was opened at 2010-04-25 19:11
Message generated for change (Comment added) made by garvinhicking
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=542822&aid=2992079&group_id=75065

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installer/Upgrader
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: J.M. Roth (jmroth)
Assigned to: Nobody/Anonymous (nobody)
Summary: make s9y friendlier for downstream

Initial Comment:
When packaging this application it 
- may be a policy not to write to /usr/share/...: which is what the native installer/upgrader does in order to write the installed version number,
- is difficult to introduce 'multi-site' behavior: according to existing instructions files would need to be installed for each user wishing to use the application.

Most problems could be alleviated by storing the currently installed version number in the database instead of some file (which the webserver user (think of suexec etc.) might not be able to modify anyhow).

Like this, the native upgrade procedure (maybe even install) could be used (simplifying the packaging) as well as easy multi-site behavior would be possible at no additional cost: each DB/site would carry its own version number, which would be automatically updated if a new release is installed in the central location. The current version number of the installed files would be available from serendipity_config.inc.php and could be compared to the version in the DB.

So my proposal: why not store actual version number in database?

(PS: Yes it is true that one might to introduce some more patches to customize the compiled template and uploads directory path and such.)

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

>Comment By: Garvin Hicking (garvinhicking)
Date: 2010-04-27 08:19

Message:
Hi!

Ah, so you're taling about general packaging...The Serendipity team itself
offers no packages, this is all done by volunteers outside of the project,
because no core developer has actual experience for this dpkg-like
packaging.

So I can only speak for the Serendipity-Core side of things, were we
really need a userspace local configuration. Serendipity always needs a
local configuration, because it is targeted for a usual
Webspace-environment, where people upload files via FTP to their local
configuration, and they never use serve-rside packaging tools. This is our
primary goal, and s9y needs to work with that primarily - all other
packaging and shared installations are currently "retrofit" to suit those
possibilities.

If we can figure out a precise way to support both, I'm all open for
suggestions. But the version number itself is not the key factor here -
even without it, as I mentioned, a local configuration is required for the
database connection storage.

The DB configuration is per-installation, so a global configuration won't
work. Each s9y installation needs to be seperated from other installations,
or you have security disclosure of other connected installations.

BTW: There are lots of people on the s9y forums that have installed s9y,
but have no knowledge of using phpMyAdmin at all! They just use the
software offered by their provider to setup an empty database, then enter
credentials into s9y, and let it do all the work. They would never be able
to execute "ALTER TABLE" commands or so, they would really need means to
use FTP or some other menu-driven design to re-execute...

I'd really like to improve the situation here, but this is all a bit vague
and in a field where I have less experience. If we can get to a possible
way of actual code changes that you need, I'd be more than happy to try to
get those aboard...

Best regards,
Garvin

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

Comment By: J.M. Roth (jmroth)
Date: 2010-04-27 07:53

Message:
Hi,

> I'm not really sure I understand this. I assume you are talking about
the
> "Shared Installation" feature specifically?

Actually, it is all intertwined. Let me write down my reasonings:

1) Having to install files for each user makes both single and shared
installs not 'nice'.

Even if you consider a single user install only, for current packaging
tools like dpkg (Debian) there is no feature to install a 'user part'
of a program (for each user), like we might know it from MSI (Windows)
etc.

2) If one wants to circumvent that, one finds out that the app version
is stored in some file that furthermore needs to be writable by the
webserver.

Even if we only consider the single user case, we still suppose the
software is installed in /usr/share (and not in his home). This one
user thus still can not write to /usr/share/... which would be
necessary to update the software. (Whatever user it is, we can say for
sure that it won't be root.)

This is the point at which I got stalled, since currently the shared
install can never work without installing at least one personal file
that has to be writable. So, currently, as far as packaging is
concerned, there would be more for the user to do, than include his
database config in some auto_prepend_file'd file, which somehow defies
the meaning of 'packaging' (which I consider making a product more or
less 'ready to use').

Generally:

To access the application I prefer setting an Alias in the webserver
configuration (instead of defining docroot to be another directory than
/var/www), thereby giving access to the relevant files in the
filesystem (while keeping the option to 'Alias' other apps to that
virtualhost) and the rest happening inside the DB. As far as the
database credentials are concerned, one can always set those using
auto_prepend_file or such.
Once these settings have been given, the ideal behavior of the app
would be to simply notice that the user/DB does not yet have
serendipity installed (or an upgrade is necessary), ask the necessary
questions, and perform it.

In order to be able to upgrade the package I have to integrate the
database update patches into some other framework. In this case
(Debian) it is dbconfig, which does not (yet) fully support shared
installations/multiple DBs for one app anyhow. This brought me to the
question of how to make s9y more compatible to handle an install (and
upgrade) itself (which then collides with the fact that the version is
stored in some text file in the file system).

> I do agree that the data in there should be as minimal as possible. But
in
> the case of installation problems, or if s9y changes the DB layer API,
it
> would be helpful to have version information outside the DB connection,
so
> that it can be modified. 

Sure, but how often does that happen? ;-)
Or if I ask the question the other way round: What does happen more
often? A new release of the software or a complete overhaul of the DB
layer API?

> Also, users for whom the upgrade failed can easily
> re-execute updates by modifying that file - for those people it would
be
> way harder to do that using possible unknown tools like phpMyAdmin for
> them?

Well I believe that someone who uses a software that stores its data
in a database should have a minimal knowledge of how to access that
database if necessary. (You are too nice ;-) )

(Ok I know the 'shared' feature is experimental anyhow... I'm just
trying to give feedback of what I feel makes sense, so consider this a
'wishlist' item)

Regards
JM


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

Comment By: Garvin Hicking (garvinhicking)
Date: 2010-04-26 07:25

Message:
Hi!

I'm not really sure I understand this. I assume you are talking about the
"Shared Installation" feature specifically?

Those should always only need to write data to their own document root,
not the shared /usr/share/... directory. serendipity_config_local.inc.php
is the local version where database credentials are held, and also the
version number.

I don't see a problem with storing that data inside there, because this
file always needs to hold DB credentials, they can't really be stored
somewhere else, so having the version number inside that file instead of
instead the database doesn't seem to make a big difference for me?

I do agree that the data in there should be as minimal as possible. But in
the case of installation problems, or if s9y changes the DB layer API, it
would be helpful to have version information outside the DB connection, so
that it can be modified. Also, users for whom the upgrade failed can easily
re-execute updates by modifying that file - for those people it would be
way harder to do that using possible unknown tools like phpMyAdmin for
them?

Maxbe if you can explain a bit more, I can better understand the issue?

Regards,
Garvin

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=542822&aid=2992079&group_id=75065

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