opensource

Upgrading / Migrating Koha from Koha 20+ to Koha 24.+

By abhisheknagar

We have already seen Koha LIS Installation in our last Post which is available @ https://abhishek.nagar.me/koha/install the same steps can be used to install the Latest Version of Koha i.e 24.11 which was released in November 2024

I am very well sure that you might be also a lazy chap like me and would be not upgraded your Koha Installation at a regular basis still i presume that you must be using at least Koha 20.05 if yes use the following procedure to upgrade/migrate your current Koha Instance to Koha 24.11

Assumption : Koha Instance Name is library, Database Name is koha_library

Step 1 ) Install Koha 24.11 using the Procedure mentioned in our earlier blog post. and yes i recommend new Installation over Upgrade as by new installation you get a easy and safe opportunity to upgrade your Base OS to Debian 12 

Step 2) Take Backup of Database from Old System

  • Open Terminal on the Old System and execute the following to take backup
  • sudo mysqldump --single-transaction -u root -p koha_library > koha.sql

Step 3 ) Move the Backup file koha.sql generated in Step 2 to new/upgraded system using scp or any backup device whatever you are comfertable with.

Step 4 ) Restore mysql Backup to the New System

  • Open Terminal on the New System and remove the Existing Database which is currently already empty
    • sudo mysql -uroot -p
    • drop database koha_library;
    • create database koha_library;
    • exit;
  • On Terminal  execute the following to restore backup (this will take time depending on the backup size)
    • mysql -uroot -p koha_library < koha.sql 
    • exit
  • On Terminal Upgrade Database Schema
    • sudo koha-upgrade-schema library
  • On Terminal rebuild the Zebra Index
    • sudo koha-rebuild-zebra -v -f library

Wohla !!! you have upgraded Koha to 24.11 :) Enjoy Open the Staff Interface with your Old Credentials as they are now migrated :)
 

 

Task Scheduling in Linux

By abhishek

In recent past i use to do certain tasks at some scheduled time on the day which also included shutting down one of my machine at 8 PM. Then I came to know that this could be effectively done automatically using cron and so I am discussing cron in this post. Cron is a daemon which schedules recurring tasks to be executed at a predefined time and date . It is very easy to schedule a job to be run at a particular time using cron. Cron daemon is typically started at boot time and runs continuously in the background. Cron maintains a table of tasks in a file named crontab which is usually in /etc directory. Each user can have separate cron file In order to access the current cron table, the crontab command is used as follows :

$ crontab -e

The above command will load the user's crontab in an editor - usually 'vi '- for editing by the user.

The crontab file contains 6 fields which are as follows :

Min Hours day-of-month month day-of-week command-to-run

And the values of these fields can take the following form:

Min - 0-59 Hours - 0-23 day of month - 1-31 month - 1-12 or Jan-Dec day of week - 0-7 or Sun-Sat

Fields in a crontab may be separated by any number of tabs or spaces. And a '*' symbol in a field represent all valid values. Suppose I am logged in as root and want to modify a crontab file of a particular user. Then I use the '-u' switch : # crontab -u username -e And to list the crontab,

$ crontab -l

You can remove the crontab using the -r switch:

$ crontab -r

Restrict or allow user access to cron

Using the two files, /etc/cron.allow and /etc/cron.deny, root can allow or restrict a user from using cron.

System crontab files

/etc/crontab - Master crontab file /etc/cron.d/ - directory containing additional system crontab files.

The syntax of the system crontab file is slightly different from the user crontab file explained above. In the system crontab file, the sixth field is a username which will be used to execute the command in the seventh field.

Below is the listing of my system crontab file - /etc/crontab

# File: /etc/crontab SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root HOME=/ # run-parts 01 * * * * root run-parts /etc/cron.hourly 00 4 * * * root run-parts /etc/cron.daily 22 4 * * 0 root run-parts /etc/cron.weekly 42 4 1 * * root run-parts /etc/cron.monthly

As seen above, run-parts is a shell script which takes one argument, a directory name, and invokes all of the programs in that directory. The directories cron.hourly, cron.daily, cron.weekly and cron.monthly contain executables which are run by the master crontab file /etc/crontab . Thus at 4:00 every morning, all of the executables in the /etc/cron.daily directory will be run as root.

If you view the /etc/cron.daily directory, you can see a lot of executables which are run daily at a predefined time as specified in the /etc/crontab file.

In my case I added the following lines

00 20 * * * root /sbin/halt (To shut down system @ 8 PM daily)

00 13 * * 0 root /sbin/halt (To shut down system @ 1 PM on sundays)

using this I was able to automatically shutdown machines once the clocked said its time to close.

Thunderbird Signatures/Buttons

Network File System

By abhishek

Network File System

Share files in a linux network

 

Software Details:

Operating System: LINUX

Packages required: nfs server and nfs client

Version used : nfs client: 1.1.0-8 -i586

nfs server: 1.3.2 -7 -i586

Download source for nfs server package: http://pkgsrc.se/wip/linux-nfs-utils 

Scenario :

Server 192.168.0.1

Clients : 192.168.0.2 & 192.168.0.3

 

CONFIGURING NFS SERVER AND CLIENT:

There are three main configuration files you will need to edit to set up an NFS server: /etc/exports, /etc/hosts.allow, and /etc/hosts.deny .

Strictly speaking, you only need to edit /etc/exports to get NFS to work, but this would lead to an extremely insecure setup.

>>/etc/exports>>

The exports file contains a list of entries that are to be shared and how it is to be shared . For a nfs setup

this is the most important file.

SERVER SIDE:

Step 1:

Open the file using the following comand as root user:

vi /etc/exports.

Make the following entry:

/home 192.168.0.2(RW) 192.168.0.3(RO)

Then save and exit the file.

Step 2:

start the nfs server service on the server machine , use the following command as root:

service nfs start

if it is already running then :

service nfs restart

Step 3:

check if the following demons are running:

portmapper: tells requesting clients how to find all nfs services on server.

mountd: handles mounting functionality.

nfs:the network file sharing daemon.

Use the command rpcinfo -p

Step 4:

Ensure that firewalls are not running as this may restrict the clients from accessing the server.

CLIENT SIDE:

Step 1. start nfs service by using the following command:

service nfs start

Step2: Check if the following daemons are running

portmapper

nfs

At least port mapper should be running in order for nfs to work .

Use command rpcinfo -p

Step 3: create mount point on client where the nfs directory will be mounted from server.

e.g mkdir nfs

check for shared files using the following command:

showmount -e serverip

e.g showmount -e 192.168.0.1

this will show a list of directories or files that are being shared over nfs.

Step4. Finally we need to mount the shared directory on the client machine by using the following command:

mount ip adrress of server:/shared directories /mountpoint on client machine

e.g mount 192.168.0.1:/home /nfs

once mounted all contents of the shared directory will be accessible by the client.

TESTING THE SETUP:

1.> Run the rpcinfo -p command on both server and client to check whether all required services for NFS are running.

2.> Once setup is done run the showmount -e command from the client side to ensure which NFS files/directories are shared.

ADDING SECURITY TO NFS:

The basic setup of nfs does not add any kind of security to the files being shared over the network thus these

files can be accessed by an unwanted person. In order to add security to the above nfs setup there are two other files that need to be

configured :

/etc/hosts.allow and /etc/hosts.deny

These two files specify which computers on the network can use services on your machine. Each line of the file contains a single entry

listing a service and a set of machines. When the server gets a request from a machine, it does the following:

1. It first checks hosts.allow to see if the machine matches a rule listed here. If it does, then the machine is allowed access.

2. If the machine does not match an entry in hosts.allow the server then checks hosts.deny to see if the client matches a rule listed

there. If it does then the machine is denied access.

3. If the client matches no listings in either file, then it is allowed access.

The first step in doing this is to add the following entry to / etc/hosts.deny :

By adding the above entry we ensure that the portmapper daemon cannot be accesssed by any other client other than those specified in the

/etc/hosts.allow

Or we can also specify the ip addresses or hostnames of the clients whose access needs to be restriced .

N ext, we need to add an entry to h osts.allow to give any hosts access that we want to have access. (If we just leave the above lines in

h osts.deny then nobody will have access to NFS.)

portmap:all

service:hostname

e.g portmap: 192.168.0.2 , 192.168.0.3

Subscribe to opensource