Hi, On 12/14/07, MJ Ray <[EMAIL PROTECTED]> wrote: > "Galen Charlton" <[EMAIL PROTECTED]> wrote: > > On 12/13/07, MJ Ray <[EMAIL PROTECTED]> wrote: > It doesn't at the moment, but accidents will happen. _get_value() > doesn't detect when it is being run non-interactively and may keep > asking prompt() and getting the same invalid default value again and > again. Can we add the supplied default value to the valid values, > just to be sure?
Yep. > > According to my reading of Apache suexec guide, u+w is not a problem > > (g+w or o+w are, but the installer does not install any files with > > those modes). That said, I have not done any testing using suexec > > mode, and would appreciate information from anybody who has. > > I'm thinking more of the opac rewriting koha's files if any weakness > is found... I need to think more about this and hammer on it, unless > anyone else has tested it. The user owning Koha's files should not be the same as the Apache user (e.g., www-data on a default Debian install), and I can add suitably loud language to that effect in the installer's prompts. That leaves two (AFAIK) places where Koha's CGI scripts currently want to write non-temporary files: [1] edithelp.pl [2] member picture upload I'm inclined to have the installation instructions tell the installer to set up ACLs to allow write access to the affected directories rather than recommend use of suexec. Alternatively, or in addition, a setuid daemon could be written to control access to the upload directories, or (in the case of the patron images) they could be stored as BLOBs in a separate mysql database. > What case should we be optimising for? The user who downloads a first > koha and installs it to try it out? Or the library consortia? We can do both -- see below. > > Therefore, I'm not in favor of putting C4 in Perl's built-in @INC by > > default [...] > > So how does that comply with the Debian Perl policy, for example? > http://www.fr.debian.org/doc/packaging-manuals/perl-policy/ch-perl.html#s-paths That policy seems to be geared to "library" Perl modules, i.e., those intended to be shared by more than one application. That document would be more clear if it addressed the distinction between a shared Perl module versus one created simply to organize an app's code. C4 falls in the later category; there is no practical reason to install the C4 modules absent installation of the rest of Koha. There are several Debian packages for Perl web applications that follow what I'm suggesting and put the application-specific modules under /usr/share/<package>/lib, including request-tracker3.6 (i.e., RT) and cgiirc. While not all Perl web-apps do this, there is enough of a precedent. > Anyway, I think a bigger problem is requiring new users to make more > config steps. Can we optimise this for new first installs? My tree now has a mechanism to paste in the installed Perl module path for use by the command-line scripts. They now all refer to kohalib.pl to adjust @INC, and kohalib.pl in turn is set by rewrite-config.PL. In the case of a 'dev' mode install, where kohalib.pl is not munged, as usual developers will have to plan on setting PERL5LIB and KOHA_CONF. The upshot is that now, after doing an installation, no environment variables need to be set to use the command-line tools. > I don't recall why kohaversion.pl was added in August when > $C4::Context::VERSION was already there. Are we stuck with it? > Can we replace it with use C4::Context; return $C4::Context::VERSION? I don't know the history, but I do like having some kind of separation, mostly for the trivial reason that the log for C4/Context.pm wouldn't get cluttered with commits that are not really related to Context.pm itself. > If we're stuck with it, can we use kohaversion.pl with a versionnumber? > Does it mean we have to add "use kohaversion.pl ..." calls to every > script, rather than appending the version number to use C4::Context? No, we can still apply the version check to C4::Context by overriding the VERSION method -- we would need to do this anyway, as the VERSION imported from UNIVERSAL.pm croaks only if the requested version is larger than the module's $VERSION. Since I'm not aware that the C4 API is presently being designed or maintained for backwards compatibility, such a version check would have to require an exact match to be completely safe. Regards, Galen -- Galen Charlton Koha Application Developer LibLime [EMAIL PROTECTED] p: 1-888-564-2457 x709 _______________________________________________ Koha-devel mailing list Koha-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/koha-devel
