This patch adds more enable / disable flags to the koha daemon helper
scripts. This is essential as systemd does not enable units by default,
especially when using instantiation variables.
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
We found a bug when running koha-create. The systemd unit name didn't
match expected, so we've moved the unit to match the koha functions
computed value.
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
This patch moves the update-rc.d lines from koha-core to koha-sysv, so
it only fires if systemd is not in use
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
This patch removes or renames some of the debian files from koha-common
to koha-core, to avoid file clash during install
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
This patch restructures the Koha packaging to support both systemd and
SysV init systems through a clean separation of concerns.
Package hierarchy:
- koha-core: Core application files (no init system)
- koha-systemd: Native systemd units (Provides: koha-init)
- koha-sysv: SysV init scripts (Provides: koha-init, Conflicts: koha-systemd)
- koha-common: Metapackage (Depends: koha-core, koha-systemd | koha-sysv)
Changes:
- koha-core: Removed 'daemon' dependency, updated description to clarify
it provides core files without init system
- koha-systemd: Now depends on koha-core instead of koha-common, provides
koha-init virtual package
- koha-sysv: Now depends on koha-core instead of koha-common, provides
koha-init virtual package
- koha-common: Converted to metapackage that depends on koha-core and
prefers koha-systemd on systemd-based systems
- Removed koha-common.install (files now installed by koha-core)
- Simplified koha-common.postinst (metapackage has minimal logic)
Benefits:
- Clean separation between core application and init system
- Users can explicitly choose their init system
- KTD can use koha-sysv without systemd
- Modern systems get native systemd by default
- Conflicts prevent both init systems being active simultaneously
Test plan:
1. Build packages
2. Install koha-common on a systemd system, verify koha-systemd is pulled in
3. Try installing both koha-systemd and koha-sysv, verify conflict
4. Install koha-core + koha-sysv explicitly, verify it works
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
This patch introduces the koha-sysv package, which provides traditional
SysV init.d scripts for managing Koha instances. All services (Plack,
Zebra, SIP, Z3950, workers, indexers) are managed through a single init
script using the daemon wrapper.
The package includes:
- /etc/init.d/koha-common (SysV init script)
- /lib/systemd/system/koha-common.service (systemd wrapper for init.d)
This package is intended for legacy systems, containers without systemd
(like KTD), or environments where SysV init is preferred.
The package provides 'koha-init' and conflicts with koha-systemd to
ensure only one init system is active at a time.
Test plan:
1. Build and install the package
2. Start services with /etc/init.d/koha-common start
3. Verify all services start correctly
4. Check that koha-systemd cannot be installed alongside
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
This patch introduces the koha-systemd package, which provides native
systemd service units for managing Koha instances. Each service type
(Plack, Zebra, SIP, Z3950, workers, indexers) is managed as a separate
systemd unit using instance templates.
The package includes:
- 8 service templates (plack, zebra, sip, z3950, worker, worker-long,
indexer, es-indexer)
- 2 target units (koha@.target for per-instance, koha.target for global)
- Helper script (koha-systemd-ctl) for managing services
All service units include:
- KOHA_HOME environment variable pointing to /usr/share/koha
- WorkingDirectory set to /var/lib/koha/%i
- Proper user/group permissions (%i-koha)
This allows granular control over individual services per instance and
leverages systemd features like dependency management, resource limits,
and journald logging.
Test plan:
1. Build and install the package
2. Enable services for an instance
3. Verify all services start correctly
4. Check journalctl logs show no errors
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
As a continuation of bug 41919, we should limit the total number of simultaneous reports that can be run at a time.
Test Plan:
1) Set total_running_reports_per_instance_limit to 2 in your koha-conf.xml
2) Create 3 long running reports like: SELECT COUNT(*) FROM items i1 JOIN items i2 JOIN items i3 JOIN items i4 JOIN items i5 JOIN items i6
3) Run each report in turn by opening a new tab, browsing to the reports
module, and choosing to run that report
5) Note the first two continue to run, but the last one gives an error
that you have too many reports running simultaneously!
Signed-off-by: Alex Carver [Acerock7] <alex@rcls.org>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
This patch introduces a modern Vue.js-based interface for managing circulation triggers (overdue notice/status triggers), replacing the legacy Tools-based interface with a more intuitive, feature-rich administration page.
New Features
Enhanced Visibility & Navigation
- Exhaustive effective rule lists showing all rules that apply to each context
- Toggle between "all exhaustive rules" and "explicitly set rules" views
- Advanced filtering by patron category and/or item type
- Clear display of fallback/default rules for each context
Rule Management Actions
- Delete triggers (last trigger in a sequence for any given library)
- Reset entire rule sets for a given context (with safeguards)
- Edit existing triggers with improved context awareness
- Add new triggers with intelligent delay constraints
Improved User Experience
- Multi-step form wizard with clear workflow progression
- Context-aware letter template filtering (only shows applicable templates)
- Placeholder values showing fallback rules when clearing inputs
- Dynamic min/max constraints for delay values based on neighboring triggers
- Real-time form validation and feedback
- Partial page reloads (only reload affected sections, not entire page)
- Specific loading messages for different operations
Technical Improvements
- Centralized Vuex store for state management
- Reusable CirculationTriggersForm component
- API clients for libraries, circulation rules, item types, and patron categories
- Consistent async/await pattern throughout
- Separation of repositories, utilities, and services
- Improved naming consistency and code maintainability
- "Dumb" TriggersTable component for better separation of concerns
Test Plan
Prerequisites
1. Log in to staff interface with appropriate permissions (tools_edit_notice_status_triggers)
2. Ensure you have test data: multiple libraries, patron categories, item types, and notice templates
3. Navigate to Administration > Circulation triggers (new interface)
Part 1: Basic Navigation & Interface
1. Verify the new "Circulation triggers" link appears in Administration home under the Circulation section
2. Access the new interface and confirm it loads successfully
3. Verify the default view shows either "All libraries" or your logged-in library based on DefaultToLoggedInLibraryOverdueTriggers system preference
4. Confirm the interface displays a list of triggers organized by context (library/patron category/item type combinations)
Part 2: Viewing and Filtering Rules
1. Toggle between "All exhaustive rules" and "Explicitly set rules" views
- Verify "All exhaustive rules" shows inherited/fallback rules
- Verify "Explicitly set rules" shows only rules you've specifically configured
2. Test the patron category filter:
- Select a specific patron category
- Confirm only rules for that category are displayed
3. Test the item type filter:
- Select a specific item type
- Confirm only rules for that item type are displayed
4. Test combined filters (patron category + item type simultaneously)
5. Clear filters and verify all rules display again
Part 3: Adding New Triggers
1. Click "Add trigger" button
2. Step 1 - Confirm Context:
- Select Library (required)
- Select Patron category (required)
- Select Item type (required)
- Click "Confirm context"
3. Step 2 - Review Existing Triggers:
- Verify existing triggers for this context are displayed
- Note the trigger numbers and delays
4. Step 3 - Configure New Trigger:
- Enter a delay value (should be constrained by neighboring triggers)
- Try entering an invalid delay (too low or too high) - verify validation
- Set "Restricts checkouts" (Yes/No/Fallback to default)
- Note the placeholder showing the fallback value
- Select a letter template
- Verify only templates for the selected library context appear
- Set "Debarring" options if desired
- Select "Charged notice fees" if applicable
5. Submit the form
6. Verify the new trigger appears in the list without a full page reload
7. Verify success message is displayed
Part 4: Editing Existing Triggers
1. Locate an existing trigger in the list
2. Click the edit icon/button
3. Verify the form pre-populates with existing values
4. Test delay modification:
- Try changing the delay within valid bounds - should succeed
- Try changing delay beyond neighboring triggers - should show validation error
- Use the increment/decrement buttons to adjust delay
5. Test clearing values:
- Clear a field (e.g., delay or restrict checkouts)
- Verify placeholder shows the fallback/default value
- Submit with cleared value - should save as null and inherit fallback
6. Change the letter template to a different valid template
7. Submit changes
8. Verify the trigger updates in the list without full page reload
9. Verify the changes persist after refreshing the page
Part 5: Deleting Triggers
1. Identify a trigger that is the last in its sequence
2. Click the delete button/icon
3. Verify a confirmation dialog appears
4. Confirm deletion
5. Verify the trigger is removed from the list without page reload
6. Verify the deletion persists after page refresh
7. Test delete constraints:
- Try to delete a trigger that's not the last in sequence
- Verify appropriate error/warning message
Part 6: Resetting Rule Sets
1. Locate a context with explicitly set rules (not just inherited)
2. Ensure this is not the only rule set for this trigger sequence
3. Click the "Reset" button for that context
4. Verify confirmation dialog explains what will be reset
5. Confirm the reset
6. Verify the explicit rules are removed and context now shows inherited rules
7. Verify changes persist after page refresh
8. Test reset constraints:
- Try to reset when it would leave no rules for that trigger
- Verify appropriate warning/prevention
Part 7: Context-Specific Behavior
1. Test library-specific letter filtering:
- Create/edit a trigger for a specific library
- Verify only letter templates with matching branchcode or default templates appear
- Switch to a different library context
- Verify the letter list updates accordingly
2. Test default rules:
- View rules for "All libraries" / "All patron categories" / "All item types"
- Verify these are labeled as "Default rule for [context]"
- Confirm these serve as fallback for more specific rules
3. Test DefaultToLoggedInLibraryOverdueTriggers preference:
- Set preference to "Yes"
- Reload circulation triggers page
- Verify it defaults to your logged-in library
- Set preference to "No"
- Verify it defaults to "All libraries"
Part 8: Form Workflow & Validation
1. Test required fields:
- Try submitting add/edit form without selecting library - should fail
- Try submitting without patron category - should fail
- Try submitting without item type - should fail
2. Test stepper navigation:
- Start adding a trigger
- Verify you must confirm context before proceeding
- Verify you see existing triggers before editing/adding
- Verify trigger form only appears after context confirmation
3. Test cancellation:
- Start adding/editing a trigger
- Click Cancel
- Verify you return to the list without changes
- Verify no partial data was saved
Part 9: Loading States & Messages
1. On slow connections or with many rules:
- Verify "Loading context..." appears while fetching context data
- Verify "Loading rule set information..." appears while fetching rules
- Verify section-specific loading messages appear during updates
2. After form submission:
- Verify appropriate success/error messages display
- Verify loading indicators during async operations
Part 10: Permissions
1. Log in as a user without tools_edit_notice_status_triggers permission
2. Verify the "Circulation triggers" link does not appear in Administration
3. Try accessing /cgi-bin/koha/admin/circulation_triggers directly
4. Verify access is denied
Part 11: Data Integrity & Persistence
1. Create a complex set of rules with multiple triggers across different contexts
2. Refresh the page and verify all rules persist
3. Restart the Koha services
4. Verify all rules still display correctly
5. Check the database circulation_rules table:
- Verify rules are stored with correct rule_name pattern (overdue_1_delay, etc.)
- Verify null values are properly stored for inheritance
- Verify the overdue_X_has_rules rule kind is present
Part 12: Edge Cases
1. Test with no existing triggers - verify empty state message
2. Test with maximum trigger sequences (e.g., trigger 1, 2, 3)
3. Test rapid successive edits
4. Test with special characters in letter template names
5. Test browser back/forward buttons during form workflow
Part 13: Comparison with Legacy Interface
1. Access the old interface if still available (via Tools menu)
2. Create a trigger using the new interface
3. Verify it appears correctly in the old interface (if applicable)
4. Create a trigger using the old interface (if still available)
5. Verify it appears correctly in the new interface
Signed-off-by: Michaela <michaela.sieber@kit.edu>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
This change localises PERL5LIB and KOHA_HOME,
which means that any changes made to PERL5LIB or KOHA_HOME
within _do_instance() in koha-plack are confined to the specific
instance being worked on in that function.
See Bugzilla for steps on how to reproduce the problem.
Test plan:
- Apply the patch
- sudo vi debian/scripts/koha-plack
Within _do_instance after PERL5LIB is set, add the following:
echo $PERL5LIB
- sudo koha-create --request-db test1
- sudo ./debian/scripts/koha-plack --restart test1 test1 test1 test1
- Note that now PERL5LIB stays constant:
/usr/share/koha/lib:/usr/share/koha/installer:/usr/share/koha/lib/installer
- git restore debian/scripts/koha-plack
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Laura_Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
This patch updates the koha-create command to generate the random encryption key
using pwgen with the number of characters set to 32.
Test plan:
1. In ktd, create a new instance:
- sudo koha-create --create-db test1
- Check the /etc/koha/sites/test1/koha-conf.xml file and verify that the encryption_key
is having the placeholder text '__ENCRYPTION_KEY__'
2. Apply the patch and copy the new koha-create command
- git bz apply 42861
- sudo cp /kohadevbox/koha/debian/scripts/koha-create /usr/sbin/koha-create
3. In ktd, create a new instance:
- sudo koha-create --create-db test2
- Check the /etc/koha/sites/test2/koha-conf.xml file and verify that the encryption_key
is generated and has 32 characters random string.
4. Sign-off
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
This change adds File::LibMagic (via libfile-libmagic-perl)
to debian/control. The debian/control should be automatically
re-generated by debian/control.in during the package process,
but we want to record the change here anyway.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
Building on bug 41918, it would be good to limit the number of reports
a given user can run at a time. This control is config-file based as
it is tied to the server resources provided by the administrator.
Adds a new koha-conf.xml option total_running_reports_per_user_limit
(0 = disabled). When the configured limit is reached, the user is told
"You have too many reports running at the moment. Please wait for some
of them to finish before running this report again."
Note on implementation: the original patch on bz (attachment 198034)
performed a second pre-flight Koha::Reports->running call in
reports/guided_reports.pl. The bug 41918 QA follow-ups already pushed
the duplicate-running guard into Koha::Report::prep_report so it would
fire across the staff UI, svc/report and opac/svc/report. This patch
extends that same model-layer architecture rather than reintroducing
controller-layer enforcement:
- New Koha::Exceptions::Report::TotalRunning subclass of
Koha::Exceptions::Report.
- prep_report now performs a second check after the duplicate one and
throws TotalRunning when the user has total_running_reports_per_user_limit
reports of any kind already in flight.
- All three callers (guided_reports.pl, svc/report, opac/svc/report)
catch the new exception alongside DuplicateRunning, mapping it to a
new template error key total_running_reports_limit_exceeded for the
staff UI and a JSON {error: total_running_reports_limit_exceeded}
with HTTP 429 for the JSON endpoints.
Test Plan:
1) Set total_running_reports_per_user_limit to 3 in your koha-conf.xml.
2) Create 3 long-running reports like:
SELECT COUNT(*) FROM items i1 JOIN items i2 JOIN items i3 JOIN items i4 JOIN items i5 JOIN items i6
3) Run each report in turn by opening a new tab, browsing to the
reports module, and choosing to run that report.
4) Note the first three continue to run, but a fourth attempt gives
the new "too many reports running" alert in the staff UI.
5) Repeat against /cgi-bin/koha/svc/report?id=N and confirm an HTTP
429 response with JSON {error: total_running_reports_limit_exceeded}.
6) Set total_running_reports_per_user_limit back to 0 and confirm
normal behaviour resumes.
7) prove t/db_dependent/Koha/Reports.t -> 13 tests pass, including a
new subtest for TotalRunning.
Signed-off-by: Alex Carver [Acerock7] <alex@rcls.org>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This commit add the option duplicate_running_reports_per_user_limit to
koha-conf.xml. If this option is empty or 0, the feature is disabled. If
this option is enabled, Koha will limit the number of times a given
report can be run of a single Koha user.
Test Plan:
1) Apply this patch
2) Set duplicate_running_reports_per_user_limit to 1, verify previous
behavior is maintained
2) Set duplicate_running_reports_per_user_limit to 0, verify the feature
is disabled
3) Set duplicate_running_reports_per_user_limit to 2, verify Koha limits
the number of duplicates of the report to the number specified in duplicate_running_reports_per_user_limit
Signed-off-by: Alex Carver [Acerock7] <alex@rcls.org>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch fixes the debug_mode test for koha-conf.xml,
so that <debug_mode>0</debug_mode> works properly.
Test plan:
0. Do not apply the patch
1. sudo vi /etc/koha/sites/kohadev/koha-conf.xml
2. Change <debug_mode>1</debug_mode> to
<debug_mode>0</debug_mode>
3. sudo koha-plack --restart kohadev
4. ps -efww | grep "starman"
5. Note that starman is still in development mode
6. Apply the patch
7. sudo koha-plack --restart kohadev
8. ps -efww | grep "starman"
9. Note that starman is now in deployment mode
Note: this is important because running a production
system in debug/development mode can be a security risk!
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Some services ( such as CloudFlare ) use alternative heads to X-Forwarded-For. Koha should be able to use a custom header instead of X-Forwarded-For if needed.
This patch updates the feature to allow both the custom header and X-Forwarded-For to work harmoniously
For example, CloudFlare has it's own custom header.
This patch allows a site to be configured for Cloudflare's proxy before the proxy is enabled.
Test Plan:
1) prove t/Koha/Middleware/RealIP.t
Signed-off-by: Lin Wei Li <lin-wei.li@inLibro.com>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Problem:
Starting from MySQL 5.7.31 and MySQL 8.0.20, mysqldump requires the
PROCESS privilege to access tablespace metadata by default. Without
this privilege, backup operations fail with permission errors.
Solution:
Add the --no-tablespaces flag to the dbflag variable. This prevents
mysqldump from attempting to access tablespace metadata, allowing
backups to complete successfully without requiring the PROCESS privilege.
Test Plan:
1. Set up a MySQL instance (5.7.31+ or 8.0.20+) without PROCESS privilege for the Koha database user
2. Run the koha-dump script for a Koha instance:
sudo koha-dump kohadev
3. Notice the backup fails with a PROCESS privilege error
4. Apply the patch
5. Copy debian/scripts/koha-dump to /usr/sbin/koha-dump
6. Repeat step 2
7. Notice the backup now completes successfully without permission errors
8. Test restoring the dump to ensure it's valid:
zcat /var/spool/koha/kohadev/kohadev-<date>.sql.gz | tail
9. Sign-off
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
koha-elasticsearch only allows the parameters to be specified on the
command line, otherwise it'll fall back to values hard-coded in the
script. This allows default parameters to be defined in
/etc/default/koha-common when installed with the Debian packages.
It also copies the current defaults into the defaults file.
Test plan, comprehensive:
1. You will need a package setup with elasticsearch, and some records.
2. Build a package (or copy the files modified in this patch over ones
you might already have installed)
3. Modify some ES_* values in /etc/default/koha-community to your
liking. 'ES_VERBOSE' might be a good one.
4. Do an elasticsearch reindex and observe that your parameter defaults
are respected.
Test plan, simple:
1. With a git checkout:
* `sudo ln -s .../koha/debian/scripts/koha-functions.sh /usr/share/koha/bin/koha-functions.sh`
* `sudo ln -s .../koha/debian/koha-common.default /etc/default/koha-common`
2. Modify `.../koha/debian/scripts/koha-elasticsearch` around line 200
so that it prints out the variables, and see that it properly respects
modifying the defaults and/or setting the command line arguments.
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Thomas Klausner <domm@plix.at>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
By defining a default policy in the Perl module, we can easily update
it over time. Using koha-conf.xml will just be for overrides, so people
can manage their own there.
Signed-off-by: Lari Taskula <lari.taskula@hypernova.fi>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
report-uri is deprecated, replaced by report-to and Reporting-Endpoints.
To test:
1. prove t/db_dependent/Koha/Middleware/ContentSecurityPolicy.t
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds the default configuration to log4perl.conf.
Note we are passing a non-standard interface 'csp' to Koha::Logger. This is to
avoid log entries from propagating up to api-error.log.
To test:
1. prove t/db_dependent/api/v1/public/csp_reports.t
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Add /api/v1/public/csp-reports endpoint to receive and log
Content-Security-Policy violation reports from browsers.
When CSP is configured with a report-uri directive pointing to this
endpoint, browsers will POST violation reports whenever a CSP rule
is violated. These reports are logged using Koha's logging system
for administrator review.
Features:
- Public endpoint (no authentication required, as browsers send
these reports automatically)
- Logs violations at WARN level with key details (violated directive,
blocked URI, document URI, source location)
- Logs full report at DEBUG level for detailed analysis
- Accepts both application/csp-report and application/json content types
Configuration example (in koha-conf.xml csp_header_value):
...; report-uri /api/v1/public/csp-reports
Log4perl configuration to capture CSP violations:
log4perl.logger.api.csp = WARN, CSP
log4perl.appender.CSP = Log::Log4perl::Appender::File
log4perl.appender.CSP.filename = /var/log/koha/csp-violations.log
log4perl.appender.CSP.layout = PatternLayout
log4perl.appender.CSP.layout.ConversionPattern = [%d] %m%n
Also updates koha-conf.xml documentation with CSP configuration guidance.
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Lari Taskula <lari.taskula@hypernova.fi>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Add Koha::Middleware::ContentSecurityPolicy to the middleware chain
in both app.psgi and the Debian plack.psgi template.
Without this integration, the CSP feature would not work - the
middleware was created but never activated. This adds it to:
- app.psgi (development/git install)
- debian/templates/plack.psgi (opac, intranet, and intranet_svc mounts)
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Lari Taskula <lari.taskula@hypernova.fi>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This change adds "style-src-attr 'unsafe-inline';" to the default CSP policy.
The reason is that we have a lot of inline styles throughout Koha,
and it will take a long time to clean those up. Also, the WYSIWYG/TinyMCE
editor injects inline styles, so it might not be possible to forbid
unsafe inline styles in Koha.
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lari Taskula <lari.taskula@hypernova.fi>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lari Taskula <lari.taskula@hypernova.fi>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lari Taskula <lari.taskula@hypernova.fi>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds the feature to anonymize patrons from items_last_borrower table. This code is run from batch_anonymize script, which is triggered from a new cron job anonymize_last_borrowers.pl
To test:
1) apply this patch and the previous ones
2) perl installer/data/mysql/updatedatabase.pl
3) set StoreLastBorrower preference to Allow.
4) set AnonymousPatron preference to a valid patron id
5) Create a Check out followed by a Check in.
CHECK => a row should appear in items_last_borrower table with the borrower and the item number.
6) In mysql, update created_on of items_last_borrower and returndate of old_issues to two days earlier.
7) perl misc/cronjobs/anonymize_last_borrowers.pl
CHECK => borrower number in items_last_borrower is not anonymized yet.
8) Repeat step 5 and 6 but instead of two days earlier, set the new entry in items_last_borrower to three days earlier.
9) set AnonymizeLastBorrower to 'Anonymize' and AnonymizeLastBorrowerDays to 2 days.
10) perl misc/cronjobs/anonymize_last_borrowers.pl
SUCCESS => borrower number in items_last_borrower changed to AnonymousPatron id
11) repeat step 8
12) set AnonymousPatron preference to 0
13) perl misc/cronjobs/anonymize_last_borrowers.pl
SUCCESS => borrower number in items_last_borrower changed to null
14) prove t/db_dependent/Koha/Patrons.t
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Peter Moore <peter@mrcpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
When creating a new Koha instance using the two-step workflow
(`koha-create --request-db <instance>`, followed by
`koha-create --populate-db <instance>`), some log files under
/var/log/koha/<instance>/ end up with incorrect ownership.
Specifically, intranet-error.log and opac-error.log are owned
by root:root instead of <instance>-koha:<instance>-koha.
This patch fixes that.
Test plan (tailored for KTD):
1) Before applying this patch, run the following commands
inside your KTD Koha container:
$ sudo koha-create --request-db test1
$ SQLPASS=`sudo grep password: test1-db-request.txt | cut -c 16-`
$ mysql -hdb -uroot -ppassword -e "CREATE DATABASE koha_test1;"
$ mysql -hdb -uroot -ppassword -e "GRANT ALL PRIVILEGES ON koha_test1.* TO 'koha_test1'@'%' IDENTIFIED BY '${SQLPASS}';"
$ mysql -hdb -uroot -ppassword -e "FLUSH PRIVILEGES;"
$ sudo koha-create --populate-db test1
$ ls -l /var/log/koha/test1/
total 8
-rw-r--r-- 1 test1-koha test1-koha 0 Feb 9 15:35 indexer-error.log
-rw-r--r-- 1 test1-koha test1-koha 1278 Feb 9 15:35 indexer-output.log
-rw-r--r-- 1 root root 0 Feb 9 15:35 intranet-error.log
-rw-r--r-- 1 root root 0 Feb 9 15:35 opac-error.log
-rw-r--r-- 1 test1-koha test1-koha 0 Feb 9 15:35 worker-error.log
-rw-r--r-- 1 test1-koha test1-koha 1828 Feb 9 15:35 worker-output.log
-rw-r--r-- 1 test1-koha test1-koha 0 Feb 9 15:35 zebra-error.log
-rw-r--r-- 1 test1-koha test1-koha 0 Feb 9 15:35 zebra-output.log
Notice the incorrect user/group ownership on two
files: `intranet-error.log` and `opac-error.log`.
2) Apply this patch, remove the `test1` instance along
with the database request text file, and copy the
modified script to its system-wide location:
$ sudo koha-remove test1
$ sudo rm test1-db-request.txt
$ sudo cp debian/scripts/koha-create /usr/sbin/koha-create
3) Repeat the commands in Step 1. This time, the output of
the last command should resemble the following:
total 8
-rw-r--r-- 1 test1-koha test1-koha 0 Feb 9 15:42 indexer-error.log
-rw-r--r-- 1 test1-koha test1-koha 1520 Feb 9 15:42 indexer-output.log
-rw-r--r-- 1 test1-koha test1-koha 0 Feb 9 15:42 intranet-error.log
-rw-r--r-- 1 test1-koha test1-koha 0 Feb 9 15:42 opac-error.log
-rw-r--r-- 1 test1-koha test1-koha 0 Feb 9 15:42 worker-error.log
-rw-r--r-- 1 test1-koha test1-koha 1828 Feb 9 15:42 worker-output.log
-rw-r--r-- 1 test1-koha test1-koha 0 Feb 9 15:42 zebra-error.log
-rw-r--r-- 1 test1-koha test1-koha 0 Feb 9 15:42 zebra-output.log
All files should now have the correct user/group ownership.
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Jan Kissig <bibliothek@th-wildau.de>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
There has been an issue where a restart of koha-sip would sometimes not bring
the SIP server back alive. This is because we have not been waiting for
koha-sip --stop to actually stop the SIP server(s). It is then possible for a
restart to attempt the --start command while a previous instance of SIP server
is still running. As the --start command in this case is not allowed, we would
then end up not starting the SIP server(s) at all.
This patch replaces daemon --stop with start-stop-daemon --stop to ensure
koha-sip daemon actually stops.
start-stop-daemon provides us the --retry option, which we are able to utilize
in waiting for the stop process to finish.
To test:
1. Before applying this patch
2. Run this command
export SIPINSTANCE="your_koha_instance_name"
You can your_koha_instance_name using the koha-list command
3. Configure a SIP server (add some min_servers, e.g. 6, to SIPConfig.xml)
4. koha-sip --enable $SIPINSTANCE
5. koha-sip --verbose --start $SIPINSTANCE
6. Observe "Starting SIP server for ..."
7. koha-sip --verbose --stop $SIPINSTANCE; ps aux | grep $SIPINSTANCE-koha-sip
8. Observe "Stopping SIP server for instancename"
9. In the output, observe the number of SIP servers you defined in step 3, plus
one.
10. koha-sip --verbose --start $SIPINSTANCE
11. Apply this patch, or edit the koha-sip directly to get changes in place
in your environment, e.g. using command
nano $(which koha-sip)
12. koha-sip --verbose --stop $SIPINSTANCE; ps aux | grep $SIPINSTANCE-koha-sip
13. Observe "Stopping SIP server for instancename"
14. In the output, observe no more SIP servers alive
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Test plan:
Copy this file to /etc/koha.
Restart Apache.
Login to staff and hit a value builder page directly, e.g.:
YOUR_SERVER/cgi-bin/koha/cataloguing/value_builder/marc21_field_005.pl
Verify that you got redirected to 403.
Verify that you can still edit a biblio record and open e.g. the leader
plugin form.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch adds a convenient option switch to the script. It will make
it perform the action (start, stop, restart, print status) on all
defined queues ('default' and 'long_tasks', as of today).
To test, make sure you applied bug 31124:
0. Apply this patch
1. Run:
$ ktd --shell --root
k$ cp debian/scripts/koha-functions.sh \
/usr/share/koha/bin/koha-functions.sh
2. Play with all the options for:
k$ debian/scripts/koha-worker * kohadev
=> SUCCESS: All options work as expected!
Note: you should include (say) having `long_tasks` stopped, and starting
all workers with the new parameter. And the same for `--stop` and
`--start`.
3. Sign off :-D
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch adds a new configuration entry in `koha-conf.xml` for making
it possible to set a different `batch_size` for `koha-es-indexer`.
The current implementation has a default of *10* that can be overridden
using the CLI parameter `--batch_size N`.
Unfortunately, if you restart the server or the service without passing
the parameter, it will be set back to 10. This patch solves that by
adding a new config entry and making the script use it. The passed CLI
parameter will keep overridding the configured value.
To test:
1. Run:
$ ktd --shell
k$ koha-es-indexer --restart --batch_size 100 kohadev
k$ ps -ef | grep elastic
=> SUCCESS: No errors. Notice '100' is passed to the called perl script
2. Run:
k$ koha-es-indexer --restart kohadev
k$ ps -ef | grep elastic
=> FAIL: Notice '10' is the new value
3. Apply this patch
4. Run:
k$ reset_all
5. Repeat 1 and 2
=> SUCCESS: '100' is kept.
6. Try standalone `--start` too
7. Sign off :-D
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Test Plan:
* Start and enter ktd
* run koha-elasticsearch with --where, which has no effect:
debian/scripts/koha-elasticsearch --rebuild -b -v --where 'biblionumber > 427' kohadev
* But you will see some warnings like:
Unknown instance --where
Unknown instance biblionumber > 427
* Final output is: Total 435 records indexed
Apply the patch
* run the same command again:
debian/scripts/koha-elasticsearch --rebuild -b -v --where 'biblionumber > 427' kohadev
* output should be
Checking state of biblios index
Indexing biblios
Committing final records...
Total 11 records indexed
* Run `debian/scripts/koha-elasticsearch --help`
* "-w|--where" should show up in the docs
Sponsored-by: HKS3
Sponsored-by: Koha DACH Hackfest
Signed-off-by: Anke Bruns <anke.bruns@gwdg.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Now that Debian 13 (and Ubuntu 25.04) set `ssl=on` by default, we should
make the `koha-mysql` helper script disable it by default if not
configured.
This patch does that.
To test:
0. Start a Debian 13 KTD e.g. with:
$ KOHA_IMAGE=main-trixie ktd up
1. Run:
$ ktd --shell
k$ koha-mysql kohadev
=> SUCCESS: You get into the DB shell
2. Apply this patch
3. Run:
k$ debian/scripts/koha-mysql kohadev
=> SUCCESS: It works as step 1!
4. Make sure you enable SSL in my.cnf:
[client]
ssl = on
5. Repeat 1
=> FAIL: You get an error about SSL in the server being disabled
6. Repeat 4
=> SUCCESS: The patch fixes it!
7. This steps imply we reproduced the issue, and it gets fixed, while
keeping the current behavior.
8. Sign off :-D
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch mainly renames var debug_mode in both scripts when it refers
to the debugger instead of the instance's debug_mode.
Note: Removing $environment from responder, probably copied.
Test plan:
cp debian/scripts/koha-functions.sh /usr/share/koha/bin/
cp debian/scripts/koha-* /usr/sbin/
cp debian/templates/plack.psgi /etc/koha/plack.psgi
Repeat steps from patch: "Replace envvar check by calling..."
Repeat steps from patch: "Adjust koha-plack and koha-z3950-responder"
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
See comment30 and comment36.
Result of two sed's:
git grep -l test_system | xargs sed -i -e "s/test_system/debug_mode/g"
git grep -l TEST_SYSTEM | xargs sed -i -e "s/TEST_SYSTEM/DEBUG_MODE/g"
The next patch will take care of the debugger options in the plack and
z3950 responder scripts.
Test plan:
Read the patch. (Testing in next patch.)
git grep -i test_system
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Test plan:
Look at changes in this patch.
Note that we already tested these settings with former patches.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Changes to koha-plack
- Check is_test_system and -development for stack trace
- Add check on set $environment for debugger
- Move export to do_instance, remove three local's
NOTE: GIT_INSTALL ie exported for koha-plack ONLY! The debian
scripts call is_git_install.
Changes to koha-z3950-responder
- debugger needs test_system flag
- Rearrange exports before calling start_z3950 and friends.
Test plan:
Check/adjust git_install and test_system in koha-conf.xml for used
instances.
cp debian/scripts/koha-functions.sh /usr/share/koha/bin/
cp debian/scripts/koha-* /usr/sbin/
cp debian/templates/plack.psgi /etc/koha/plack.psgi
Add a die in e.g. opac/opac-main.pl.
Set test_system to 1 in koha-conf.xml or export TEST_SYSTEM=1 in your environment.
Restart Plack.
Hit opac-main. Do you see a stack trace?
Export TEST_SYSTEM=0. Restart Plack.
Hit opac-main again. You should not see a stack trace.
Start koha-z3950-responder with/without debug flag. Works as expected?
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Replace the $GIT_INSTALL check by is_git_install.
Some scripts did call is_git_install once while potentially looping over
multiple instances.
Note: koha-reset-passwd only runs on one instance (unlike most).
Test plan:
Check/adjust git_install and test_system in koha-conf.xml for used
instances.
cp debian/scripts/koha-functions.sh /usr/share/koha/bin/
cp debian/scripts/koha-* /usr/sbin/
Note: We will still test koha-plack and -z3950-responder later.
Test running a few of the other changed koha-* scripts on one or more
instances. Verify that things work as expected.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Test plan:
Check if git_install is set correctly for your system
in koha-conf.xml. Adjust otherwise.
cp debian/scripts/koha-functions.sh /usr/share/koha/bin/
cp debian/scripts/koha-* /usr/sbin/
Run koha-shell your_clone. Does that works like expected?
Run t/Koha/Config.t.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Resulting from the following sed statement:
git grep -l DEV_INSTALL | xargs sed -i -e "s/DEV_INSTALL/GIT_INSTALL/g"
Test plan:
Read the patch.
The scripts will be tested later on.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Logical follow-up for moving away from dev_install to git_install.
Result of running
git grep -l adjust_paths_dev_install | xargs sed -i -e "s/adjust_paths_dev_install/adjust_paths_git_install/g"
Test plan:
Read the patch.
The scripts will be tested later on.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Test plan:
Copy koha-functions.sh to /usr/share/koha/bin.
Source bin/koha-functions.sh ('. bin/koha-functions.sh')
Test in bash (Yes expected; adjust instance name):
GIT_INSTALL=1; if is_git_install your_instance; then echo Yes; fi
Add/set git_install to 1 in koha-conf.xml.
Test in bash (Yes expected):
unset GIT_INSTALL; if is_git_install your_instance; then echo Yes; fi
Set git_install to 0 in koha-conf.xml.
Test in bash (No expected):
unset GIT_INSTALL; if ! is_git_install your_instance; then echo No; fi
Remove git_install and add/set dev_install to 1 in koha-conf.xml.
Test in bash (Yes expected):
unset GIT_INSTALL; if is_git_install your_instance; then echo Yes; fi
A few similar tests with test_system.
Add/set test_system to 0 in koha-conf.xml.
Test in bash (Yes expected):
TEST_SYSTEM=1; if is_test_system your_instance; then echo Yes; fi
Test in bash (No expected):
unset TEST_SYSTEM; if ! is_test_system your_instance; then echo No; fi
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
See also comment33, point 4.
Test plan:
cp debian/templates/apache-shared-opac-antibot.conf /etc/koha/
Test enabling/disabling by toggling the comment of the SetEnvIf line,
restart apache and remove the KOHA_INIT and CGISESSID cookie.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch adds a fast simple bot challenge via Apache.
To test:
0. Apply the patch
1. sudo cp debian/templates/apache-shared-opac-antibot.conf /etc/koha/.
2. sudo cp debian/templates/apache-shared-opac-plack.conf /etc/koha/.
3. curl http://localhost:8080/cgi-bin/koha/opac-search.pl
4. Note an instant response with a very simple HTML response
5. Open an incognito browser and go to http://localhost:8080/cgi-bin/koha/opac-search.pl
6. Note a very brief loading animation before the OPAC search page appearing
7. Do a search
8. Note no more loading animation appears
9. Close the incognito browser
10. Open an incognito browser and go to http://localhost:8080/cgi-bin/koha/opac-main.pl
11. Do a search via the "Library catalog" search bar
12. Note no loading animation appears
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Cornelius Hertfelder <cornelius.hertfelder@bsz-bw.de>
Signed-off-by: Magnus Enger <magnus@libriotech.no>
We have tested this in production on at least three live sites for
several weeks, and it has worked as expected. We have not noticed any
negative side effects.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch adds more module search paths to the zebra-biblios-dom.cfg and zebra-authorities-dom.cfg, so that a larger range of CPU architectures will work with Zebra search unit tests.
This will not change Debian package installs, but it will fix any git-based installs.
TO TEST (you'll need access to an ARM-based CPU, and, preferably, an x86-64 machine):
ON THE ARM-BASED MACHINE:
a) start ktd, then ktd --shell
b) in ktd, run: prove -v t/db_dependent/Search.t
c) notice how the test now fails
APPLY PATCH
d) rerun step b
e) notice how the test now passes
ON THE X86-64-BASED MACHINE:
f) run steps a-e
g) notice how the test passes, both before and after applying the patch
SIGN OFF
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: David Flater <flaterdavid@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
this patch adds some useful features to allow the build-git-snapshot tool to build production packages
the patch adds the following options:
--urgency, -u
the urgency string for the resulting package. Default is '$urgency'.
--incr, -i
set debian revision (default = '-1')
--(no)autochangelog
whether or not to update the debian/changelog file.
Default is to update it.
note: this patch does not change any of the existing behaviour of the tool
test plan to come...
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Test plan:
Just read the patch.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch applies the same logic to `koha-disable`.
Signed-off-by: Magnus Enger <magnus@libriotech.no>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Taking advantage of the `get_worker_queues` function introduced in bug
31124, this patch makes `koha-create` start all defined queues.
To test:
1. Run:
$ ktd --shell
k$ sudo -s
k$ koha-create --create-db test
=> FAIL: No mention of `long_tasks`
2. Apply 31124 and then this patch
3. Run:
k$ cp debian/scripts/koha-functions.sh \
/usr/share/koha/bin/koha-functions.sh
k$ debian/scripts/koha-create --create-db test1
=> SUCCESS: `long_tasks` worker is started
4. Sign off :-D
Signed-off-by: Magnus Enger <magnus@libriotech.no>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch makes two things:
* Adds a `get_worker_queues` function to koha-functions.sh
* Makes `koha-remove` loop through all the defined queues to stop all
the running workers before trying to remove the unix user for the
instance.
To test:
1. Run:
$ ktd --shell
k$ sudo -s
k$ koha-create --create-db test1
k$ service koha-common restart
k$ koha-remove test1
=> FAIL: There's an error about not being able to drop the instance user
2. Run:
k$ ps -ef | grep test1
=> FAIL: There's a running process for the 'long_tasks' queue worker.
3. Apply this patch
4. Run:
k$ cp debian/scripts/koha-functions.sh \
/usr/share/koha/bin/koha-functions.sh
5. Repeat 1 naming the instance `test2`
=> SUCCESS: The instance is removed correctly. No error about running
processes
=> SUCCESS: No process is running for `test2`
6. Sign off :-D
Signed-off-by: Magnus Enger <magnus@libriotech.no>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch adds the base vue app as well as the component to list vendors
Amended-by: Jonathan Druart
chmod 755 acqui/vendors.pl
Signed-off-by: Michaela Sieber <michaela.sieber@kit.edu>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Nothing to do here, libpod-coverage-perl 0.23 is available in all debian
versions
Signed-off-by: Baptiste Wojtkowski <baptiste.wojtkowski@biblibre.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
The koha-mysql didn't work when the instance was set up to use an encrypted
database connection.
Please note: this testplan is for ktd, not for a production environment!
Unfortunately, there are some issues with the database TLS configuration in koha-testing-docker.
This is described comment 14 of bug 36026 (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36026#c14)
As a workaround, you can add "mysql_ssl_optional=1" in Koha/Database.pm.
See point (g) in comment 15 of bug 36026 (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36026#c15)
Testing Database Connection Encryption:
1. Apply the patch.
2. Configure koha-conf.xml to use a TLS connection
(see comment 10 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36026#c10, follow steps 3a-g + 4 )
3. Run:
koha-mysql <koha_instance>
4. Verify that the MySQL console opens successfully.
5. Check the encryption settings in the MySQL console:
- run:
SHOW VARIABLES LIKE '%ssl%';
- run:
STATUS;
Ensure that the following conditions are met:
- have_openssl and have_ssl are set to "YES".
- The SSL cipher in use is displayed.
Testing MySQL Timezone Configuration:
1. Apply the patch.
2. Configure the timezone in koha-conf.xml, for example:
<timezone>Antarctica/South_Pole</timezone>
3. Run:
koha-mysql <koha_instance>
4. Verify that the MySQL console opens successfully.
5. Check the timezone setting in the MySQL console by running:
SELECT @@session.time_zone;
6. Confirm that the output matches the timezone configured in koha-conf.xml.
Sponsored-by: Karlsruhe Institute of Technology (KIT)
Signed-off-by: Jan Kissig <bibliothek@th-wildau.de>
Signed-off-by: Thomas Klausner <domm@plix.at>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch fixes koha-upgrade-schema so that it returns an exit
code of 0 whether or not a DB change is needed. This is important
so that koha-common.postinst proceeds correctly even when there
is no DB change needed (e.g. for 24.11.03-2)
Test plan:
0. Apply the patch
1. cp debian/scripts/koha-upgrade-schema /usr/sbin/koha-upgrade-schema
2. dpkg-reconfigure koha-common
3. Note the process completes correctly
4. koha-upgrade-schema kohadev
5. Note following text appears very quickly:
Upgrading database schema for kohadev
No database change required
6. koha-mysql kohadev
update systempreferences set value = '24.1102000' where variable = 'Version';
7. Clear memcached
8. koha-upgrade-schema kohadev
9. Note that it applies the 24.11.03 database upgrade
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
It will be a commented line in the debian template and added also
in the crontab.example file.
As mentioned on BZ, the comment can easily be removed automatically
during Docker builds or startups etc.
Test plan:
Just read the patch. Nothing changes here actually.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Test plan:
NOTE: Needs dev_install or ktd.
[1] Add a die in a script somewhere to simulate a crash.
For example in opac-main.pl: die "Line 43";
[2] Run koha-plack --restart YOUR_CLONE (without -dev) and hit that page.
See no dev output?
[3] Run koha-plack --restart -dev YOUR_CLONE and hit page again.
See dev output?
[4] BONUS: Do a koha-plack --reload YOUR_CLONE (without -dev). Hit page.
Verify that environment did not change.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Note that --errlog should refer to all output from the wrapper daemon
process only like respawning processes etc.
And that --output should refer to all output from the daemonized
client process (so in our case the SIP server).
Moving a few sip.log occurrences to sip-output in that regard.
Test plan:
Restart koha-sip.
Login to sip server.
Restart koha-sip.
Verify that you see Net::Server messages and traces from the login in the
-output log. The restarts are not found however in -error. See my comment
on the BZ report.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
No need for three files here (and badly specified).
We can just use sip.log.
Test plan:
Run koha-sip and verify that logging is still done as expected.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
test plan:
1. check run order of scripts in the cron
2. apply patch
3. koha-run-backups is now at the beginning of the cron
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch adds the Log4perl configurations required to match the
existing prior use of Log4perl in EDI code.
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
this patch removes unneeded package dependencies
to test:
- apply patch
- build and install koha-common package, note success
Signed-off-by: Magnus Enger <magnus@libriotech.no>
Not tested, I trust Mason to the right thing.
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
- Look at debian/scripts/koha-dump
- The description of --exclude-indexes reads:
"Include Zebra indexes on the backup"
- Apply the patch
- Look at the file again. The description is now:
"Exclude Zebra indexes from the backup"
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
- Copy the koha-worker script to the standard location:
$ sudo cp debian/scripts/koha-worker /usr/sbin/koha-worker
- Check "sudo koha-worker --help" and verify elastic_index is
not mentioned in the list of "current queues"
- See https://wiki.koha-community.org/wiki/Testing_man_pages for
how to check the "man" page. elastic_index should not be
mentioned in the list of "Current queues".
- Both places aboce should have a note about elastic_index not
being active when koha-es-indexer is running.
Signed-off-by: Sukhmandeep Benipal <sukhmandeep.benipal@inLibro.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
tar has exit status 1 if any file has changed while being read, which is likely to happen as the logfiles are included. this patch will catch these harmless errors so that koha-dump will still return a success code.
Test plan:
1. Create a number of backups and edit their modify time to being older than 2 days
2. run the koha-run-backups script and try and write to one of the files it includes while it's being backed up (you'll trigger a warning from tar saying the file changed as it was being read)
3. verify that the older backups are not being cleaned up and deleted despite new backups being made.
4. Apply this patch
5. Complete steps 1-2 again and then go and look to see if the older backups are being deleted.
Sponsored-by: Catalyst IT
Signed-off-by: David Nind <david@davidnind.com>
Co-authored-by: Michał Kula <148193449+mkibp@users.noreply.github.com>
Signed-off-by: Michał Kula <148193449+mkibp@users.noreply.github.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Not sure how this is coming from, neither why we have not noticed that
before, but "sound" is listed under `koha-translate --list`
It's coming from `ls koha-tmpl/intranet-tmpl/prog`
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This change adds the ability to enable and configure TCP keepalive
support for the SIP server using SIPconfig.xml.
For the sake of backwards compatibility, it defaults to disabled
and additional parameters default match typical kernel defaults.
Technical detail can be found in the perldoc for C4/SIP/SIPserver.pm
Test plan:
0. Apply the patch
1. koha-sip --restart kohadev
2. apt-get update && apt-get install tcpdump
3. In one window, run "tcpdump -A -n -v -i any 'port 6001'"
4. In another window, run the following:
echo -e "9300CNterm1|COterm1|CPCPL|\r" | nc 127.0.0.1 6001 -v
5. Note in tcpdump output that after the initial flood of packets,
nothing more is received
6. vi /etc/koha/sites/kohadev/SIPconfig.xml
7. In the "server-params" element, add attributes like the following:
custom_tcp_keepalive='1'
custom_tcp_keepalive_time='10'
custom_tcp_keepalive_intvl='5'
8. koha-sip --restart kohadev
9. In one window, run "tcpdump -A -n -v -i any 'port 6001'"
10. In another window, run the following:
echo -e "9300CNterm1|COterm1|CPCPL|\r" | nc 127.0.0.1 6001 -v
11. Note in tcpdump output that after the initial flood of packets,
ACK packets are sent out every 10+ seconds for the idle connection
Signed-off-by: Tadeusz „tadzik” Sośnierz <tadeusz@sosnierz.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
The cron can take a very long time to run on systems with many issues.
For example, a partner with ~250k auto_renew issues is taking about 9 hours to run.
If we run that same number of issues in 5 parallel chunks
( splitting the number of issues as evenly as possible ), it could take under 2 hours.
Test Plan:
1) Generate a number of issues marked for auto_renew
2) Run the automatic_renewals.pl, use the `time` utility to track how much time it took to run
3) Set parallel_loops to 10 in auto_renew_cronjob section of config in koha-conf
4) Repeat step 2, note the improvement in speed
5) Experiment with other values
Signed-off-by: Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
When an unauthorized call to svc is made, we use the ErrorDocument middleware to respond with an HTML
page. The API doens't do this, it simply returns its status. We should mount the svc as its own app to avoid
the redirect to HTML for unauthorized responses
To test:
1 - Create a report
2 - Add to IntranetUserJs:
$(document).ready(function() {
// Your report ID
var reportId = '492';
// Fetch the report
$.get('/cgi-bin/koha/svc/report?id=' + reportId, function(data) {
console.log('Kaboom');
});
});
3 - Log out
4 - Attempt to login
5 - KO
6 - Apply patch
7 - Reset all (or copy the necessary changes to your plack/apache files)
8 - Generate report and update user js again
8 - Logout, login
9 - Success!
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Note that -gt is the bash integer comparison and > is the
lexical one:
$ if [ '1' \> '09' ]; then echo true; fi
true
$ if [ '1' -gt '09' ]; then echo true; fi
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
[EDIT] Added the dev/null redirection to suppress warn in bin/sh.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
After execution of koha-elasticsearch command a file named 0 remains in
the current directory.
Inside the single parentheses, the character '>' is treated as a file
redirection, not as a comparison operator.
Test plan:
==========
1. Have a test installation with Elasticsearch. As root, perform:
./debian/scripts/koha-elasticsearch --rebuild kohadev
When the command finishes, check the contents of the current
directory (ls -ltr | tail). You sould notice a fresh file named '0'
2. Apply the patch. Delete the file named 0.
3. Repeat p. 1. There should be no file named 0 now.
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>